resize just the pixels near left/right edges to fill frame?

[bennynihon]

Using AutoCrop I noticed a lot of Blu-ray movies actually have a couple lines of black pixels on both the left and right side that make it a bit troublesome for encoding. So instead of 1920 horizontal pixels, there's really just 1916. I'd like to keep my resolution mod16 to improve encoder efficiency a bit, so I have two options.

I could chop off 8 pixels on each side, but that would remove a bit of actual data and when watched on a TV it will inevitably have to resize this 1904 wide movie to 1920 anyways. So I'd prefer to resize it up front, by first cropping to 1916 and then resizing to 1920. But in doing so, I only want to touch the pixels near the edge and leave the large majority of pixels in the middle of each frame untouched. Is there a way to stretch the last N rows of pixels on each side to fill in those 2 missing pixels? So if N were 8, it would stretch those last 8 rows of pixels on each side to 10 pixels giving me 1916 to 1920.

[StainlessS]

I seem to recall a WarpResize plug.

EDIT: If you are still interested after Colors post below, then here tis: http://web.archive.org/web/20130207143129/http://neuron2.net/trbarry/downloads.html

Part of SimpleResize (EDIT: Oops, Colors already posted link below).

[colours]

The inefficiency incurred from not using a mod-16 width is not worth caring about. Also, these:

http://avisynth.nl/index.php/Crop
http://avisynth.nl/index.php/Resize
http://avisynth.nl/index.php/StackHorizontal

WarpedResize (http://web.archive.org/web/20140420184002/http://neuron2.net/trbarry/SimpleResize.zip) would still warp the centre of the image by some imperceptible amount, but even a normal resize from 1904 to 1920 would be imperceptible anyway so there's no point using that if you want to satisfy your own requirements exactly.

[bennynihon]

This would seem to work, though for some reason the right side clip is a garbled mess. If I crop it directly, as opposed to doing it within the resize function it looks good.

Crop(2,132,1916,816) # crop to 1916x816 to remove black bars
vCenter=BicubicResize(1888,height,0,0.75,14,0,-14,0)
vLeft=BicubicResize(16,height,0,0.75,0,0,-1902,0) # use 14 pixels on left/right edge to fill in to 16 pixels
vRight=BicubicResize(16,height,0,0.75,1902,0,0,0)
StackHorizontal(vLeft,vCenter,vRight)

Changing BicubicResize to BilinearResize worked. I suppose Bicubic is sampling outside of the picture resulting in the garbage

UPDATE: fixed code above

[bennynihon]

The inefficiency incurred from not using a mod-16 width is not worth caring about

Right, but there's still the issue with my TV set resizing from 1916 to 1920 and slightly distorting the picture. I'd rather take control of the situation and do the resizing myself and not effect the majority of the picture (we're talking about 2 pixels on each side, so better to just touch up the edge and keep the majority of the frame untouched). And since I'm already handling the resizing, keeping it mod16 is a nice little side benefit :)

[wonkey_monkey]

Crop(2,132,1916,816) # crop to 1916x816
vCenter=Crop(14,0,-14,0)
vLeft=BicubicResize(16,height,0,0,-1902,0) # take 14 pixels on left/right and resize to 16 pixels
vRight=BicubicResize(16,height,1902,0,0,0)
StackHorizontal(vLeft,vCenter,vRight)

Changing BicubicResize to BilinearResize worked. I suppose Bicubic is sampling outside of the picture resulting in the garbage

By cropping before resize, you're robbing bicubicresize of some of the pixels it would otherwise use, and run the risk of introducing a (possibly barely visible) line. A bicubicresize tends to have a sharpening effect at edges.

I'd take twice as much as is required, resize that, then crop it in half before stacking it back with the main image.

[StainlessS]

Changing BicubicResize to BilinearResize worked

BiCubic is a peculiar one

BicubicResize (clip, int target_width, int target_height, float "b=1./3.", float "c=1./3.", float "src_left",
\ float "src_top", float "src_width", float "src_height")

[bennynihon]

By cropping before resize, you're robbing bicubicresize of some of the pixels it would otherwise use, and run the risk of introducing a (possibly barely visible) line. A bicubicresize tends to have a sharpening effect at edges.

I'd take twice as much as is required, resize that, then crop it in half before stacking it back with the main image.

Actually I'm only cropping off the black pixels first. Then I crop within the BicubicResize call for creating the left,center, and right components.

[colours]

Also note that using BicubicResize with any b value other than 0 makes it a non-interpolatory filter (like GaussResize) which is not a good idea since it can potentially introduce a visible discontinuity when spliced together with the unresized centre section. b=0, c=0.5 would be ideal in this scenario.

(I say "visible", but this is relative to the fact that it's very close to the outer edge of the video frame and you wouldn't really notice anything there while watching. It's just a matter of pedantry.)

[Wilbert]

Also note that using BicubicResize with any b value other than 0 makes it a non-interpolatory filter (like GaussResize)
Could you explain? Why is it a non-interpolatory filter and what's special about the case b=0?

[bennynihon]

BiCubic is a peculiar one

BicubicResize (clip, int target_width, int target_height, float "b=1./3.", float "c=1./3.", float "src_left",
\ float "src_top", float "src_width", float "src_height")


good catch! assigning all parameter values fixed my issue.

Crop(2,140,1916,800) # 1920x800/1280x532 (2.40:1 AR)
vCenter=BicubicResize(1888,height,0,0.75,14,0,-14,0)
vLeft=BicubicResize(16,height,0,0.75,0,0,-1902,0)
vRight=BicubicResize(16,height,0,0.75,1902,0,0,0)
StackHorizontal(vLeft,vCenter,vRight)

So I did a quick little test comparing 4 crop/resize cases of a 5 minute section of a movie. Original clip is 1920x800 (with the 2 rows of black pixels on the left and right sides). All other settings are equal

1.) Original with black strips: 101,823 KB
2.) Cropped to remove black strips, no resize (non-mod16): 97,817 KB
3.) Cropped to remove black strips, resized back to 1920x800: 93,135 KB
4.) Cropped to remove black strips, separate Bicubic resizing of left/right edges and stacked with middle to create 1920x800: 101,837 KB

The black strips and the sharp edges they create leads to the largest file size for #1. The simple cropping of the black strips, which creates a non-mod16 resolution in #2, isn't all that bad. Cropping the black strips away and resizing back to 1920x800 to make it mod16 in #3 led to the smallest file size, which isn't too surprising. The results of just resizing the portion near the outer edges, as in #4, doesn't give a seamless enough transition and although it looks great to the naked eye, the encoder obviously struggles a bit with this case. So I'm left with either cropping away the black strips and encoding at a non-mod16 resolution, or resizing the entire clip to fill it to 1920 (a mod16 resolution). Since my TV/PC is going to resize it to 1920 anyways, I might as well do so myself and gain the smaller file size benefit in the process. Thanks all for the help

[Asmodian]

I believe you are reading too much into the sizes after compression, or rather being smaller after compression can also indicate lower quality.

3) is so small in part because the resize has blurred the image some, sharp images are larger after compression.
4) This is because you have added extra information and still have a sharp line. If you want easier to compress instead of an ideal appearance there is a lot more you could do. I believe simply duplicating the outer edge image pixel to fill in the black compresses fairly well, or mirroring the outer few is even better. :)

[bennynihon]

I believe you are reading too much into the sizes after compression, or rather being smaller after compression can also indicate lower quality.

3) is so small in part because the resize has blurred the image some, sharp images are larger after compression.
4) This is because you have added extra information and still have a sharp line. If you want easier to compress instead of an ideal appearance there is a lot more you could do. I believe simply duplicating the outer edge image pixel to fill in the black compresses fairly well, or mirroring the outer few is even better. :)

agreed that a blurrier image will compress better, though we're talking about going from 1916x800 to 1920x800, so the impact on sharpness will be minimal. Cropping away 8 pixels on each side (no resizing) and keeping it mod16 is also smaller. But I'm OK with the resize since encoding it at 1916 horizontal resolution will be resized by any playback device to fit my display (typically 1920 for an HDTV) and will "blur" the image anyways. I might as well resize it myself and benefit from a higher quality resize and lower encoded file size.

I've also thought about duplicating or mirroring the pixels on the edge to fill in those 2 rows on each side. That's a good idea, though I'm not entirely sure how to accomplish this in Avisynth. Any suggestions? Thanks

I'm doing this at the moment to mirror the 2 rows of pixels on the left and right edges. Not sure if there's a better way

Crop(2,140,1916,800) # 1920x1080 -> 1916x800
vLeft=Crop(0,0,-1914,0).FlipHorizontal
vRight=Crop(1914,0,0,0).FlipHorizontal
StackHorizontal(vLeft,last,vRight)

[Reel.Deel]

Take a look at Padding (http://forum.doom9.org/showthread.php?p=1596804#post1596804).

[bennynihon]

I'm doing this at the moment to mirror the 2 rows of pixels on the left and right edges. Not sure if there's a better way

well, mirroring just the last two rows resulted in a comparatively big file, so I will likely just resize the entire clip especially in light of the fact as mentioned before, that any playback device will have to resize a cropped movie anyways and impact the quality.

[wonkey_monkey]

I might as well resize it myself and benefit from a higher quality resize and lower encoded file size.

But you're resizing before compression, which is worse than letting the TV resize after compression.

[bennynihon]

But you're resizing before compression, which is worse than letting the TV resize after compression.

When going from 1916 to 1920 horizontal resolution, I'd say that's up for debate. Impact on encoder would be marginal and you do give it the benefit of working on a mod16 resolution. But I'm glad you brought that up, because it can't be ignored