View Full Version : AVIsynth does not do "proper" bilinear downscaling
Katie Boundary
24th May 2017, 04:16
Use any standard-definition (720x480) progressive footage.
mpeg2source("1AKY01.d2v")
A=bilinearresize(352,240)
B=simpleresize(360,240).bilinearresize(352,240)
compare(A,B)
The mean absolute deviations will be much larger than what the rounding errors from simpleresize should produce.
Also, as I'm looking through external resizing filters on the wiki, I'm seeing stuff about "chroma shift caused by the internal resizers when they're used on horizontally subsampled chroma with MPEG2 placement." Has this been fixed? Is it the reason why Arearesize gives me slightly different colors than AVIsynth's internal resizing filters?
hello_hello
24th May 2017, 05:29
I love the new signature. It effectively says "assume Katie knows everything", but as you don't it doesn't cover the contingency where you want to do a very bad thing but don't know how bad it is. Take de-interlacing by separating the fields, decimating and resizing, for example.
I'm not sure why your resizing should be the same so it's probably another case of Katie incorrectly assuming something is broken. According to the Avisynth help files, Bilinear resizing performs some antialiasing whereas it seems SimpleResize does not. I don't know anything about AreaResize but an an "area-average resizer" seems to imply it might produce a somewhat different result.
The subpixel shift doesn't change the colours. It moves the chroma relative to the luma by a very small amount. Nothing you'd see as it's less than a pixel shift for normal amounts of resizing. There's resizing scripts/plugins that resize the chroma correctly for mpeg2 placement (Avisynth's resizers effectively assume mpeg1).
mpeg-1 versus mpeg-2 sampling (http://avisynth.nl/index.php/Sampling#mpeg-1_versus_mpeg-2_sampling)
Resize8 (http://avisynth.nl/index.php/Resize8) (which I tend to use) can be edited to rescale with your preferred resizing and you can specify chroma placement, although it assumes mpeg2. It'll also use different resizing for luma and chroma if you wish, and it'll also use different resizing for upscaling and downscaling. Or there's ResizeX (https://pastebin.com/raw/0BjFT0bM) or I think the Dither Package resizes chroma without the shift. There's probably others.
https://forum.doom9.org/showthread.php?p=1506374#post1506374
We can quantify the shift as follows.
For YV12 and YUY2, the chroma centre is 0.5 luma pixels to the left of the luma centre.
When resizing from width Win to Wout, output pixel spacing in terms of input is multiplied by Win/Wout.
Hence the net (rightwards) chroma shift is a distance of 0.5*(1-Win/Wout) input luma pixels.
For a 2x upsize, this equals 0.25, for a 2x downsize it's -0.5 (ie 0.5 to the left).
TheFluff
24th May 2017, 23:21
What do you mean, "proper"? What bearing does trbarry's old asm-only garbage from 2002 have on the comparison? What were you expecting to see, exactly? Have you actually looked at what the simpleresize output looks like, visually? It ain't pretty.
StainlessS
25th May 2017, 01:57
I would like to be able to disagree with the fluffy one, but cannot, the fluffy one, rules. :)
Katie Boundary
25th May 2017, 07:16
What do you mean, "proper"?
https://forum.doom9.org/showpost.php?p=1708640&postcount=50
What bearing does trbarry's old asm-only garbage from 2002 have on the comparison?
Well, I would have used reduceby2, except that it's implemented in a mathematically incorrect way for performance reasons. I also could have used bilinearresize(360,240).bilinearresize(352,240), but that's just a more computationally expensive way of doing the same thing as what's actually in the script. If you know of an AVIsynth filter that performs mathematically correct downscaling using a 2x2 non-overlapping matrix, please tell me about it.
What were you expecting to see, exactly?
If bilinear downscaling was implemented correctly, we'd see mean absolute differences in the range of 0.0001, not ~0.5
Have you actually looked at what the simpleresize output looks like, visually? It ain't pretty.
At a scaling factor of exactly 1/2 in both directions, it should produce the exact same output as a triangle filter and even a hermite cubic.
TheFluff
25th May 2017, 13:32
oh boy here we go again, where is colours when you need him
I think vivan may have meant the opposite of what you think he meant, but disregarding that, why are you expecting the two resampling paths you outlined to produce exactly the same results?
Katie Boundary
25th May 2017, 14:51
oh boy here we go again, where is colours when you need him
I think vivan may have meant the opposite of what you think he meant, but disregarding that, why are you expecting the two resampling paths you outlined to produce exactly the same results?
Because that's how Vivian said "proper" bilinear downscaling works.
And they wouldn't be EXACTLY the same. They'd produce slightly different rounding errors.
hello_hello
25th May 2017, 17:53
If bilinear downscaling was implemented correctly, we'd see mean absolute differences in the range of 0.0001, not ~0.5
Where did that theory come from? A bottle of Vodka?
Never ending fuss and the output is VCD resolution anyway.....
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.