GOUT image stabilization - Released — Page 35

NAB is nominal analogue blanking.  It means that eight pixels on the left and eight pixels on the right (for NTSC) are junk and do not count toward the calculation of the aspect ratio. They can be discarded.

I do not want an anamorphic mkv, because the player will do a better job of resizing this than the filter.  It would be like playing an AVI on a PS3:  It would be scaled up, no problem.  :-)

I have been playing with deleting the anamorphic resizing section of the script and replacing the cropping line with:

Crop(8,96,-8,-96,align=true)

When I do this, the vertical resolution ends up doubled though...  :-(

Guys,

Maybe it would help to state what the design goals were:

1. stabilize the image. 2. Anti-alias 3. Remove over-sharpening artifacts 4. crop off the border over-sharpening that couldn't be removed from the convolution.

One thing to keep in mind is that the Anti-Aliasing filter is a line doubler. You MUST resize afterwards unless you want an image that is stretched vertically. The entire script really is not as compartmentalized as the comments in the script would lead you to believe. If you really want to do away with the resize, you also have to remove the anti-aliasing.

The other thing to keep in mind is that the borders of the original were put in after telecine, so they don't move with the shakiness of the image. SO, when you do the image stabilization, NOW the borders move. Bummer right? So SOME cropping is justified. Yeah, one could argue that your TV won't display the edges anyway due to overscan... But not everyone is watching these on a TV. No harm done just blacking out what you don't want and what the TV doesn't show anyway, right?

One other thing. I know everybody thinks Spline32 is better than Spline16, but I could never see the difference, and the script ran just a bit faster with Spline16, so I went with it. I really don't feel too strongly about that, so if anyone can show some even slight improvement with Spline32, I would definitely change the script.

I kinda like discussing the finer details of the script, but please keep in mind that it's been a while, so I may be a little fuzzy on the exact details. I expect a small re-learning curve once I jump back into it to get the convolution for ROTJ done.

-G

g-force said:

One thing to keep in mind is that the Anti-Aliasing filter is a line doubler. You MUST resize afterwards unless you want an image that is stretched vertically.

Ah!  That explains why the vertical height was doubled when I took the resize out!  Now I understand why the resize is there, everything is good.

g-force said:  Yeah, one could argue that your TV won't display the edges anyway due to overscan... But not everyone is watching these on a TV. No harm done just blacking out what you don't want and what the TV doesn't show anyway, right?

No harm at all!  :-)  Was the resizing done in a NAB aware way though?  You are of course right that not everyone watches on a TV, but to me that makes 704x480 even more appealing, as you will see no pillarboxing on a PC or a TV as long as both are set right.  It is this line I do not understand:

Spline16Resize(728,388).Crop(8,14,-6,-10,align=true).AddBorders(3,58,3,58)

As to which resizer is in the script, it does not matter, as people can change it to whatever they want anyway.

I have taken snapshots of the original into photoshop and followed G-Force's resizing step-by-step.  He is removing the borders so they do not shake after the stabilization and cropping into the picture on the top and bottom to remove that nasty faint line (technical term is?) that is running by the black border top and bottom, which is great, but I am virtually certain that the cropping and resizing does not take NAB into account. 

For an anamorphic 704x480 DVD, I would change resizing line to:

Spline16Resize(720,384).Crop(8,14,8,-10,align=true).AddBorders(0,58,0,58)

This might be a tiny bit faster, before the resizing stage, as the image being processed is a tiny bit smaller, and it would avoid the need for horizontal resizing.  Alternatively, if you must author a 720x480 DVD you could make the resizing line:

Spline16Resize(720,384).Crop(0,14,0,-10,align=true).AddBorders(0,58,0,60)

Actually, DE, if the Anti-Aliasing filter is a line doubler and there has to be a vertical resize anyway, one might as well make this anamorphic, do you not think?

I will just stick to what g-force has, it works and it looks very DAMN good, I see no need to change anything really, keep up the great work g-force, looking forward to Jedi hopefully sometime soon.

As far as speed goes, it only takes overnight to render a lossless avi and only a couple hours to encode, so the speed is just fine to.

Oh, yes, I agree that G-Force's work is amazing, and I am really grateful to him.   If there is no need to resize horizontally, it should look better--that is all.  :-)

boba feta said:

Isn't cropping the image early defeating the purpose?

We are just cropping off the black borders so we are filtering a clean image only, then resizing and adding back the appropriate size borders for 16:9 anamorphic video.

I have been watching this thread for months, and I still don't know WTF you guys are talking about, LOL!  I was backing up my Dr. Gonzo's and was reminded of how bouncy the image is, and was wondering if my LD's were truly that bad too, but I no longer have a player.

Wow, some serious scripting!  You guys are truly amazing.

Definitely count me in for wanting to see the final products!

boba feta said:

Isn't cropping the image early defeating the purpose?

How do you mean?  The cropping would still be at the same point in the script; it would just crop horizontally a little as well as vertically.  If what you say is true though, it could be moved back to the resize stage.

edited - I think 10 and -14 as cropping values do have to change though.  My logic was faulty there.

I would be grateful if someone could check the vertical cropping values that I changed.  I think they are right.

Chewtobacca said:

I would be grateful if someone could check the vertical cropping values that I changed.  I think they are right.

Sure, I would be more than happy to check the values, but what are the final final changes you are proposing?

-G

g-force said: Sure, I would be more than happy to check the values, but what are the final final changes you are proposing?

-G

Thanks, G-Force!  It was just this part from my earlier post.

For an anamorphic 704x480 DVD, I would change the cropping command near the beginning of the script to:

Crop(8,96,-8,-96,align=true)

and the resizing line later on to:

Spline16Resize(704,384).Crop(0,12,0,-10,align=true).AddBorders(0,58,0,60)

I changed vertical cropping to 12 and -10 because obviously the values have to change if one no longer resizes horizontally.  I take it the purpose of cropping into the image is to remove that ugly line that runs parallel to the borders.  I appreciate your help and really admire all this work you are doing.  :-)

Maybe I'm missing something, but what's the benefit to a 704x480 DVD vs a 720x480 DVD?  It has less resolution, so why is that good?

No, it has the same effective resolution.  The extra pixels are junk.  They can be there or not, and it makes no difference to the image displayed on a correctly calibrated TV. Look up nominal analogue blanking, but it is hard to understand at first.  Darth Editous was kind enough to explain it to me.

As I posted before, one can just as easily author a 720x480 DVD with the script.  It makes no difference.  That is not what I think needs to change.  It is the horizontal resizing (728x388) that is unnecessary.  Cropping to 704x288 as opposed to 720x288 might be a tiny bit quicker though, and, as this script is exceedingly slow, I will take that small improvement.  I am rendering now and it is taking ages. :-D

LOL you guys must be on slow PC's.

Compared to yours I certainly am!  This looks like it will take a couple of days... :-O

Chewtobacca said:

Compared to yours I certainly am!  This looks like it will take a couple of days... :-O

I totally feel your pain, my last PC before this one took that long, it sucked, especially if you find something wrong and have to do it all over again.

dark_jedi said:  especially if you find something wrong and have to do it all over again.

You had to say it!  LOL!  I just realized that I forgot to delete Info() from the end of the file.  Doh!

*sound of head banging against wall*

Oh, well, off we go again.  This is the resize I am using for a non-anamorphic MKV, by the way:

Spline36Resize(720,316).Crop(8,12,8,-8,align=true).AddBorders(0,4,0,4)

Now someone can come in and check it and find another error and make me start all over again.

I've watched the sample and I like what I see!  I can't wait for the final products to be available to us!

Oh.

Chewtobacca said:

Thanks, G-Force!  It was just this part from my earlier post.

Crop(8,96,-8,-96,align=true)

Crops about 4 more pixels off from the right side than I found you need to for ANH and 2 more than you need to for ESB, but maybe that's your preference. If you do this before image stabilization, then your left and right borders are going to move. If you do it after the stabilization, you just wasted a lot of processing on the borders. Maybe you better break up where you do the vertical and horizontal crops.

Chewtobacca said:

obviously the values have to change if one no longer resizes horizontally.

That would be true, if I had been resizing by A LOT or cropping A LOT, but I was zooming by a factor of 1.011. I'd have to be cropping later in the script by more than 100 to make the values change even 1 pixel. I think my max crop is 14, so the values of the crops shouldn't change.

-G

g-force said:  Crops about 4 more pixels off from the right side than I found you need to for ANH and 2 more than you need to for ESB, but maybe that's your preference. If you do this before image stabilization, then your left and right borders are going to move.

The borders will move inwards relative to their position on the original image (if you see what I mean.)  It does crop into the image more than you did, but no more than is needed, as the eight pixels on either side of the original are never meant to be seen and are not seen during playback.  Even though you are cropping what looks like part of the picture, you are really not, as that part of the picture could just as easily be black pixels: it would make no difference. 

By the way, I did not check this for ANH yet, just for ESB, but from looking at your ANH script will make no difference.

That would be true, if I had been resizing by A LOT or cropping A LOT, but I was zooming by a factor of 1.011. I'd have to be cropping later in the script by more than 100 to make the values change even 1 pixel. I think my max crop is 14, so the values of the crops shouldn't change.

-G

I see what you mean.  Those values can stay then.  You are just cropping out that ugly line, are you?  There is no other purpose to the crop?  If so, then that is good, as I have judged the crop values visually in Photoshop for my non-anamorphic MKV, which obviously has to have different crop values as it is resized to 720x316

Thanks, G-Force!  I appreciate this. :D