Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion. Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules. |
23rd December 2008, 18:20 | #1 | Link |
Avisynth language lover
Join Date: Dec 2007
Location: Spain
Posts: 3,431
|
ReduceBy2() introduces chroma shift
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
Code:
BilinearResize(Width()/2, Height()/2, 0.5, -0.5) Code:
MergeChroma(BilinearResize(Width/2,Height/2,0.5,0.5), BilinearResize(Width/2,Height/2,1.0,1.0)) Code:
MergeChroma(BilinearResize(Width/2,Height/2,0.5,0.5), BilinearResize(Width/2,Height/2,1.0,0.5)) |
23rd December 2008, 18:27 | #2 | Link |
AviSynth plugger
Join Date: Nov 2003
Location: Russia
Posts: 2,183
|
Gavino,
your post is plagiarism
__________________
My Avisynth plugins are now at http://avisynth.org.ru and mirror at http://avisynth.nl/users/fizick I usually do not provide a technical support in private messages. |
23rd December 2008, 19:27 | #3 | Link |
Avisynth language lover
Join Date: Dec 2007
Location: Spain
Posts: 3,431
|
Yes, Fizick, well spotted.
The description of 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? |
23rd December 2008, 20:35 | #4 | Link |
Sleepy overworked fellow
Join Date: Feb 2008
Location: Maple syrup's homeland
Posts: 933
|
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.
__________________
AnimeIVTC() - v2.00 -http://boinc.berkeley.edu/- Let all geeks use their incredibly powerful comps for the greater good (no, no, it won't slow your filtering/encoding :p) |
23rd December 2008, 21:26 | #5 | Link |
AviSynth plugger
Join Date: Nov 2003
Location: Russia
Posts: 2,183
|
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.
__________________
My Avisynth plugins are now at http://avisynth.org.ru and mirror at http://avisynth.nl/users/fizick I usually do not provide a technical support in private messages. |
23rd December 2008, 23:10 | #6 | Link |
Avisynth Developer
Join Date: Jan 2003
Location: Melbourne, Australia
Posts: 3,167
|
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.
Code:
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 |
24th December 2008, 06:27 | #7 | Link |
Sleepy overworked fellow
Join Date: Feb 2008
Location: Maple syrup's homeland
Posts: 933
|
You do have a point here
qft
__________________
AnimeIVTC() - v2.00 -http://boinc.berkeley.edu/- Let all geeks use their incredibly powerful comps for the greater good (no, no, it won't slow your filtering/encoding :p) |
24th December 2008, 07:47 | #8 | Link |
Avisynth Developer
Join Date: Jan 2003
Location: Melbourne, Australia
Posts: 3,167
|
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. |
24th December 2008, 19:54 | #9 | Link |
AviSynth plugger
Join Date: Nov 2003
Location: Russia
Posts: 2,183
|
can anybody with modern CPU make some speed comparing of Reduceby2 with BilinearResize?
__________________
My Avisynth plugins are now at http://avisynth.org.ru and mirror at http://avisynth.nl/users/fizick I usually do not provide a technical support in private messages. |
25th December 2008, 11:35 | #10 | Link |
LaTo INV.
Join Date: Jun 2007
Location: France
Posts: 701
|
on a C2D E8400@4gHz and a 7680*4320 source:
Code:
ReduceBy2() ReduceBy2() ReduceBy2() ReduceBy2() Code:
BilinearResize(Width()/2, Height()/2) BilinearResize(Width()/2, Height()/2) BilinearResize(Width()/2, Height()/2) BilinearResize(Width()/2, Height()/2) |
Tags |
reduceby2 |
Thread Tools | Search this Thread |
Display Modes | |
|
|