I can add some to the "works" list: Death To Smoochy, Signs, Shawshank Redemption. Unfortunately those are the only ones I've tested on so far :D.

I don't have any of those discs you mentioned, so if updating your avisynth.dll doesn't help then I guess I'll be approaching it from a theoretical direction...

:D Success! The problem was with avisynth 2.06. Upgraded to 2.07 and gripfit now works. That may solve some of my other problems as well. Thanks Sansgrip!

Cool! One fewer thing to worry about ;).

Here's preview 0.0c with another new feature (I really should make a release already ;)). Instead of:

one would now use:

As you can see, I split "GripFit" into "GropCrop" and "GripSize". Surprisingly, GripCrop now just crops existing borders (ala RemoveBorders), and GripSize does the resizing. GripBorders adds borders, as usual.

I did this so that it's possible to insert filters between the crop (so that they run faster) and the resize (so that they can operate on the full-size image). Many people do this as a matter of routine, since it makes smoothers less aggressive than running them after the resize.

I can think of a bunch of other stuff I want to add (such as auto-detection of anamorphic source material) but that'll have to wait until after I've written the docs and got 0.1 out of the door.

Let me know if you have problems :).

That's GREAT SansGrip!
But I’m just wondering… as a cosmetic issue and to make it a bit clearer
isn’t it good to have the resize values in the GripSize function? :roll:

It would be clearer, I agree. Unfortunately all the work is done in GripCrop, and GripSize simply takes the values stored by GripCrop to use when resizing. You see, if GripCrop doesn't know what the target size is, it can't work out how much to crop the clip to maintain aspect ratio.

The only other option would be to specify the target size in both GripCrop and GripSize, but I think that would be even worse than the current way :).

a little more height
 

Hi SansGrip,

Is it possible for GripFit to cut a little more on left/right side of the frames
to gain more height for movies in 1:2,35 or 1:2,40 format?

I don't like the small picture-bar of such movies, but i love GripFit....

regards, ***mfb***

Re: a little more height
 

At the moment it's not possible to alter the crop behaviour, but you can force it to cut more from the sides by doing this:

The Letterbox line will make 16-pixel black borders left and right before GripCrop sees the clip. GripCrop will then crop these black borders off, effectively doing what you want. You can of course use any value you like -- 16 is just an example.

Thanks - I'll give it a try and I'am hoping that you will include such a
function in further version of your great GripFit.

regards, ***mfb***

That's what I was going to ask...

Is it possible to reduce the width of the clip without reducing the height too? because Blcoks-Overscan is a good thing, but it just sucks that the height is reduced too... That makes Lord Of The Rings For example almost unwatchable at TV Overscan 2... it's just too small of a picture... in fact the top and bottom borders are bigger than the actual movie... :cry:

This will give you two overscan blocks left and right, but none top and bottom.

Wouldn't this change a little the original aspect of the movie? I know it's a little, but it won't be the original. Or am I wrong :?:

-kwag

No, because the pixel aspect ratio remains the same. All it's doing is blacking out the left and right edges. It should still display correctly on the standalone.

At least I think that's the case. I'll ponder it while I walk my daughter to school ;).

Edit: It'll change the display aspect ratio of the active portion of the frame, but not the pixel aspect ratio, so it'll still display correctly on the standalone (and in WinDVD etc.)

@Jellygoose

Could you give me some figures from your LOTR encode? It will help me decide how to implement what you ask for. I need to know:

- All the GripXxx lines from your script
- The size of the original, unaltered frame
- The size of the existing borders as worked out manually by you
- The size of the frame after GripCrop
- The size of the frame after GripSize

That should give me something to work with :).

what's the latest version of GripFit_preview.dll?
 

@SansGrip,

Is 0.0c the latest version? Are there docs?

Thanks

Re: what's the latest version of GripFit_preview.dll?
 

Yep.

Not yet -- I'm still bug-fixing and adding the features I want in the first release, 0.1. Once the feature-set has stabilized I'll finish the docs and make a release :).

Just to clarify what I was saying, releasing 0.1 is pretty high on my to-do list. At the moment I'm still testing to make sure that it's matching the result from FitCD pretty closely (working backwards from the rounded resize to the cropping-to-maintain-aspect-ratio part is proving trickier than I first thought). I also need to add a way to override its border-detection for difficult movies (e.g. those with subtitles in the border), and try to figure out how to do overscan borders on one plane only (i.e. left and right or top and bottom but not both) while maintaining aspect ratio, or if this is even necessary given the latest fixes I've done.

Also somewhere near the top of my to-do list is recompiling my Avisynth 2.5 filters for the latest build, and finishing drywalling the dining room (my wife wants me to nudge that last one a little higher on my list) :mrgreen:.

ooh fun! I just finished drywalling a giant doghouse I built :D

Did you insulate? :mrgreen:

This is the first time I've done drywalling, and it's going quite well I think... I'm mudding at the moment and getting more on myself than on the wall, but it's slowly taking shape ;).

yep, insulated with R-11 and wired it too :wink: The biggest mistake I used to make when taping is that I'd tape over large gaps (>1/4") and large bubbles would form behind the tape- solve that by filling the gaps with mud- let it dry, then tape! :lol:

lol. Dog's gotta have his reading light ;).

Yep, that's what my neighbour told me to do. It's a pain in the ass waiting 24 hours between each coat, but I've had bad experiences taking "short cuts" before so I think I'll do what the book says this time ;).

sorry for the bit of wait...

ok, here's the script:
Ok, I'm not really experienced with this whole resizing thing, so you plrobably have to tell me again what to do...
Source is DVD PAL (720x576)...
FitCD Tells me (overscan 0, no cropping) that the original borders are (0,72,0,72), and the video size is then 720x432...

is that what you asked for? I know there's a way to get all those information with VDub, but I didn't find it...

How does FitCD tell you that...?

I also need to know the size of the frame after GripCrop, and again after GripSize. You can do this in VDub by loading the avs then going to file->file information.

Hey Sansgrip

Tipps on drywall if you want......
Depending on how thick your mud is of course.
Your mud for taping should be thinned down...reason when it dries it will shrink ...this sucks your tape close to your drywall.
You will not have such a large hump to try and flaten out later.
If you have large gaps between your sheets this thin mud will have no backing ...gives you bubles......Use un thinned mud to fill your larger cracks ......scrape off excess mud then tape over with thined out mud .
Use thick mud for second coat ...you don't want to much shrinkage here . Tthinned mud or toping coat for last coat .....goes on thinner gives better sanding and easyer to feather edge.

have a great day

Interesting -- I did the second coat yesterday. I was having some trouble getting the edges feathered, and it was also drying real quick. Maybe I'll try thinning it a little next time :idea:.

Thanks :).

Re: a little more height
 

I just used the above on a SVCD conversion, and it worked _excellent_! I too had been annoyed that adding overscan blocks cause the movie to resize itself to the point where the borders added together were bigger than the visible film area. Adding the 16 pixel border to each side gave the little bit of extra compression without compromising screen size. Thanks!

Re: a little more height
 

You should never see borders bigger than the film area, unless your encoding a really weird AR. The most extreme I've come across -- 2.35:1 -- will, if the frame height is 480, produce an active height of ~272, meaning the borders will together be ~208.

However, I do understand what you're saying. I think I shall add this functionality into GripFit, where you can choose either to add overscan by resizing or by letterboxing.

Now, if only I could remember everything I said I would add to this next release... ;)

Here's an idea for an overscan implementation that I'd like some feedback on before I code it up...

At the moment GripCrop measures existing borders on all edges, then crops them off. GripSize then resizes to whatever dimensions GripCrop calculated to be correct. Let's say GripCrop decided on a target width of 528: it would then have subtracted (16 * overscan) pixels from that, and decided on the new height accordingly. This is the reason that the active image is becoming so small, especially if you use 2 overscan blocks.

What if, instead of resizing to say (528 - 16 * 2), GripSize actually resized to the full 528, then simply blacked out 16 pixels on each edge? That way you'd retain a decent height for the active image area.

The other possibility is if GripCrop only cropped the top and bottom borders from the source material, leaving the left and right borders intact. GripSize would then resize to the full width (say 528) and GripBorders would black out the pixels as above. The advantage of this approach is that you lose less of the information you would see in the source material. The disadvantage is that any filters run between GripCrop and GripBorders would also process any existing left/right borders, but these are usually negligible.

Thoughts?

This one sounds interesting :D

-kwag

Not sure I see the real difference there, except where the 'work' is being done (GripSize vs. GripCrop). After using FaeryDust() on a few samples, I'd always jump for the one that is going to be faster :)

I'm a little confused why your second method is going to lose 'less' information... the end result is that 16pixels from each side are getting blacked out, so the picture that is visible will be the same for both.

If the source material has, say, 6-pixel borders left and right, then cropping them off, resizing to whatever width, and blacking out the borders will lose more information than resizing with those borders and then blacking out.

How about using ClipFrame in TMPGEnc with that new technique and mask the borders in TMPGEnc... wouldn't that solve the problem of applying noise and smoothing to the borders?

Nope. It would be exactly the same as how GripFit works right now, and more hassle ;).

Yep... I agree with kwag.
That's what I usually do with letterbox.

I also agree with you that it's negligible. :wink:
And if we use GripBorder (that’s where you’ll insert the letterbox, isn’t it?) after the filters, the noise that could be left by the filters in the borders will be letterboxed, and will not be transmitted to the encoder.

So how do I use Letterbox together with GripFit?
Where to put the Letterbox line?

I would also like to know where to put the letterbox as well as the gripborders line?

That information can be gleaned from past posts in this thread -- but soon I shall be releasing a new version (hopefully 0.1 proper) which will offer this functionality built in.

Well, from the previous posts, it sounds like Gripborders() may be taking the place of letterbox(0,0,16,16). Is this the case?

Hey everbody it has been like a month since iwas on this website. Geez January was a nice month for this site all these new developments. Could anyon be nice enough to show me couple scripts showing this gripfit and the applications of the new and best combination of filters. Thanks

branden

You don't need to use Letterbox with GripFit. It's just a hack I came up with in response to a question about overscan.