ReduceBy2() introduces chroma shift

[Gavino]

A 'feature' of ReduceBy2() is that, unlike the standard xxxResize filters, it does not preserve the position of the image center. Thus, for RGB clips, it turns out that ReduceBy2() is equivalent to
BilinearResize(Width()/2, Height()/2, 0.5, -0.5)

However, for YV12 and YUY2 clips, the chroma is shifted by a different amount from the luma. For YV12, it is equivalent to
MergeChroma(BilinearResize(Width/2,Height/2,0.5,0.5), BilinearResize(Width/2,Height/2,1.0,1.0))
and for YUY2
MergeChroma(BilinearResize(Width/2,Height/2,0.5,0.5), BilinearResize(Width/2,Height/2,1.0,0.5))
This appears to move beyond being a feature and IMHO enters 'bug' territory.

[Fizick]

Gavino,
your post is plagiarism
;)

[Gavino]

Yes, Fizick, well spotted. ;)

The description of ReduceBy2() (http://avisynth.org/mediawiki/ReduceBy2)'s behaviour is lifted almost directly from the changes you recently made to the wiki (extending a change I made after discovering the basic 'feature').

Do you agree the chroma difference is a bug?

[thetoof]

fwiw, it is a bug since the name of the function implies a "reduction by 2", not the necessity of using xxxresize afterwards to correct a (totally useless and bogus) chroma shift caused by that reduction, which may lead to inappropriate resizing, not because of a user error, but a problem inherent to the function.

[Fizick]

thetoof,
chroma is "reduced by 2" truely :)

Gavino,
Center shifting (at least luma) was known many years.
This function is fast and dirty resize. In many case some chroma shift is not very important.
But generally, this function is obsolete (like some others) and should be avoided.

May be we should remove it in v2.6 or 2.7 (like some others).
Or replace to BilinearResize internally - but it can break some scripts.
I am not sure.
Probably the best solution (currently) is: documented bug is feature. :)
But we must properly document it (I am going to change the offline doc at CVS too tomorrow).
BTW, Ben's text about "320x240" resolution is quite obsoleted too. :)



BTW, SimpleResize plugin has other "bug-feature" with "wrong" scale ratio.

[IanB]

Yes, the filter does as advertised. It does a 121 kernel reduce by 2. It's a quick and dirty filter. Perhaps explaining the algorithm might sooth the ruffled feathers.
dst[0]=(src[0]+2*src[1]+src[2]+2)/4
dst[1]=(src[2]+2*src[3]+src[4]+2)/4
dst[2]=(src[4]+2*src[5]+src[6]+2)/4
...
dst[n]=(src[2*n]+src[2*n+1]+1)/2

[thetoof]

thetoof,
chroma is "reduced by 2" truely :)
You do have a point here ;)

Probably the best solution (currently) is: documented bug is feature. :)

qft

[IanB]

I wish people would stop with the "bug" word regarding code that works exactly as intended but they just happen to dislike/disagree with it. Especially when the issue is a well known performance related compromise.

By all means discuss the issue, offer alternatives, document it, just don't mention "bug".

For a 3 tap, 121, fixed kernel algorithm the current behaviour is all that should be expected. Avisynth is full of code that sails the compromise line and I don't regard 1 line of any of this code as bugged due to the performance compromise adopted. Back when we had 166Mhz Pentium MMX's doing realtime 320x240 8bit was the goal, and these algorithmic compromises were the order of the day. Now we have 3+Ghz Core2 Duo's but we want to do 1920x1080 10bit in realtime again algorithmic compromises are required.


I kind of like to do a google "plugh xyzzy bug site:forum.doom9.org" and not get threads like this polluting the results.

[Fizick]

can anybody with modern CPU make some speed comparing of Reduceby2 with BilinearResize?

[LaTo]

on a C2D E8400@4gHz and a 7680*4320 source:


ReduceBy2()
ReduceBy2()
ReduceBy2()
ReduceBy2()

= 9 fps


BilinearResize(Width()/2, Height()/2)
BilinearResize(Width()/2, Height()/2)
BilinearResize(Width()/2, Height()/2)
BilinearResize(Width()/2, Height()/2)

= 6 fps