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.

 

Go Back   Doom9's Forum > Capturing and Editing Video > Avisynth Development

Reply
 
Thread Tools Search this Thread Display Modes
Old 23rd December 2008, 18:20   #1  |  Link
Gavino
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)
However, for YV12 and YUY2 clips, the chroma is shifted by a different amount from the luma. For YV12, it is equivalent to
Code:
MergeChroma(BilinearResize(Width/2,Height/2,0.5,0.5), BilinearResize(Width/2,Height/2,1.0,1.0))
and for YUY2
Code:
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.
Gavino is offline   Reply With Quote
Old 23rd December 2008, 18:27   #2  |  Link
Fizick
AviSynth plugger
 
Fizick's Avatar
 
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.
Fizick is offline   Reply With Quote
Old 23rd December 2008, 19:27   #3  |  Link
Gavino
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?
Gavino is offline   Reply With Quote
Old 23rd December 2008, 20:35   #4  |  Link
thetoof
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)
thetoof is offline   Reply With Quote
Old 23rd December 2008, 21:26   #5  |  Link
Fizick
AviSynth plugger
 
Fizick's Avatar
 
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.
Fizick is offline   Reply With Quote
Old 23rd December 2008, 23:10   #6  |  Link
IanB
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
IanB is offline   Reply With Quote
Old 24th December 2008, 06:27   #7  |  Link
thetoof
Sleepy overworked fellow
 
Join Date: Feb 2008
Location: Maple syrup's homeland
Posts: 933
Quote:
Originally Posted by Fizick View Post
thetoof,
chroma is "reduced by 2" truely
You do have a point here

Quote:
Originally Posted by Fizick View Post
Probably the best solution (currently) is: documented bug is feature.
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)
thetoof is offline   Reply With Quote
Old 24th December 2008, 07:47   #8  |  Link
IanB
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.
IanB is offline   Reply With Quote
Old 24th December 2008, 19:54   #9  |  Link
Fizick
AviSynth plugger
 
Fizick's Avatar
 
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.
Fizick is offline   Reply With Quote
Old 25th December 2008, 11:35   #10  |  Link
LaTo
LaTo INV.
 
LaTo's Avatar
 
Join Date: Jun 2007
Location: France
Posts: 701
on a C2D E8400@4gHz and a 7680*4320 source:

Code:
ReduceBy2()
ReduceBy2()
ReduceBy2()
ReduceBy2()
= 9 fps

Code:
BilinearResize(Width()/2, Height()/2)
BilinearResize(Width()/2, Height()/2)
BilinearResize(Width()/2, Height()/2)
BilinearResize(Width()/2, Height()/2)
= 6 fps
LaTo is offline   Reply With Quote
Reply

Tags
reduceby2

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 00:24.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.