Minimizing Resize Blur

[Seraphic-]

Hi,

I have several 720p (1280x720) videos that have five unusable pixel lines (two right, two bottom, one left).
Wanted to crop them out, but then the video is no longer mod16.
The next mod16 would be 1264x704, but it seems like a waste to throw away that many extra pixels.

Used the below code (which should crop first and re-size second) as a base to do some testing, but is there something else that would help keep blurring to a minimum (close to the original as possible)?

Spline36Resize(1280,720,1,0,-2,-2)
limitedsharpenfaster(strength=10)

Thanks

[Sagekilla]

Only thing that would keep blur to a minimum would to be using a sharp resizing kernel, of which spline 36 happens to be. As I said before though, you'll be very hard pressed finding the difference.

[CruNcher]

Don't you find this a little bit crazy, i mean croping Film content is one thing to save bits and precission but come on somewhere has to be a line drawn your fugeling arround with the source in that way will hurt more then help. My advice is to leave it like it is and encode it that way else you just wasting energy (especialy harm the input), if you dont have a realy realy good reason for doing this imho :)

[Seraphic-]

Don't you find this a little bit crazy, i mean croping Film content is one thing to save bits and precission but come on somewhere has to be a line drawn your fugeling arround with the source in that way will hurt more then help. My advice is to leave it like it is and encode it that way else you just wasting energy, if you dont have a realy realy good reason for doing this imho :)

Well, the reason would be that the two pixel lines on the right and bottom are black (no information), the one pixel line on the left has a darken overlay.
So the point was to have all pixels that were to be encoded be fully visible.
For some reason, Xbox360 outputs its 720p games this way.

http://www.temp.seraphicgate.com/720p360.jpg

[IanB]

If it's black borders that are bothering you just use BorderControl (by Si W) to duplicate the adjacent line into the 1 or 2 lines of black border.

[Seraphic-]

If it's black borders that are bothering you just use BorderControl (by Si W) to duplicate the adjacent line into the 1 or 2 lines of black border.

Yeah, they bother me, but not in the way you think.
Wanted to remove them so the video only consisted of fully visible pixels.

[Didée]

Try to resize only the borders. That way the majority of pixels stays 100% untouched, and the cheat is not as obvious as when using BorderControl.

If the stretch still seems too obvious, replace all 16's with 32.

stackhorizontal(
\ last.spline36resize(16,height(),1,0,16-1,height()),
\ last.crop(16,0,-16,-0),
\ last.spline36resize(16,height(),width()-16,0,16-2,height()) )

stackvertical(
\ last.crop(0,0,-0,-16),
\ last.spline36resize(width(),16,0,height()-16,width(),16-2) )

[Seraphic-]

Try to resize only the borders. That way the majority of pixels stays 100% untouched, and the cheat is not as obvious as when using BorderControl.

If the stretch still seems too obvious, replace all 16's with 32.

stackhorizontal(
\ last.spline36resize(16,height(),1,0,16-1,height()),
\ last.crop(16,0,-16,-0),
\ last.spline36resize(16,height(),width()-16,0,16-2,height()) )

stackvertical(
\ last.crop(0,0,-0,-16),
\ last.spline36resize(width(),16,0,height()-16,width(),16-2) )

Thanks, gave your above code a try and it looks like using 32 is more obvious then 16.
But you might want to be the judge of that since I'm not sure how this works.

Also, maybe it would be better to drop the re-size of the one left pixel line.
It really is not noticeable unless you zoom in.
Would this be correct to remove the left pixel edit?

stackhorizontal(
\ last.crop(0,0,-16,-0),
\ last.spline36resize(16,height(),width()-16,height(),16-2) )

stackvertical(
\ last.crop(0,0,-0,-16),
\ last.spline36resize(width(),16,0,height()-16,width(),16-2) )

(RAW)
http://www.temp.seraphicgate.com/raw.jpg

(16)
http://www.temp.seraphicgate.com/16.jpg

(32)
http://www.temp.seraphicgate.com/32.jpg

[Didée]

Would this be correct to remove the left pixel edit?
Yup, seems correct to me.

...it looks like using 32 is more obvious then 16.
But you might want to be the judge of that since I'm not sure how this works.
Me? No. It's your project, so *you* have to judge.

However: you shouldn't compare by switching between original and cheated version ... that way, it's of course _very_ obvious that the borders are cheated.

Make a test encode of a version with either 16 or 32, play that encode. Watching only this, ask yourself if you (really) can tell that something fishy is happening in the border regions.

BTW, what about AA? - There's lots of stairstepping ... ;)

[Seraphic-]

Yup, seems correct to me.


Me? No. It's your project, so *you* have to judge.

However: you shouldn't compare by switching between original and cheated version ... that way, it's of course _very_ obvious that the borders are cheated.

Make a test encode of a version with either 16 or 32, play that encode. Watching only this, ask yourself if you (really) can tell that something fishy is happening in the border regions.

BTW, what about AA? - There's lots of stairstepping ... ;)

Thanks, I'll do some more tests.
Could you go over what exactly this process is doing?

Also, doesn't adding AA cause a good amount of smoothing and blurring?
Still, do you know of any guides that list the different scripts for adding AA along with script descriptions?

[Avenger007]

So what's the necessity of using mod16?
x264 could encode non-mod16 videos just as easily.