ConvertToRGB strangeness or bug

[WarpEnterprises]

I found something I cannot explain myself.

If you make a rgb frame e.g. with the following script:


pt = "YUY2"
r=BlankClip(width=8, height=8, length=100, color=$ff0000, pixel_type=pt)
g=BlankClip(width=8, height=8, length=100, color=$00ff00, pixel_type=pt)
b=BlankClip(width=8, height=8, length=100, color=$0000ff, pixel_type=pt)
stackhorizontal(r,g,b)
converttorgb32()

this comes out:
http://www.avisynth.org./warpenterprises/mod4.gif

If you change to non-mod4-width, which should really be no problem for YUY2:

pt = "YUY2"
r=BlankClip(width=10, height=8, length=100, color=$ff0000, pixel_type=pt)
g=BlankClip(width=8, height=8, length=100, color=$00ff00, pixel_type=pt)
b=BlankClip(width=8, height=8, length=100, color=$0000ff, pixel_type=pt)
stackhorizontal(r,g,b)
converttorgb32()

this comes out:
http://www.avisynth.org./warpenterprises/nonmod4.gif

If you magnify the images you'll see that the mod4-Version has blended vertical edges, which is not the case in the nonmod4-version.
It is not the case, too, if you feed VirtualDub the YUY2 video.

Why this? Is the conversion broken since 2.06 or am I making something very silly.

(it does not make a difference how you get the source image).

[IanB]

WarpEnterprises,

Someone went to a lot of trouble to put chroma interpolation into the MMX ConvertToRGB() and didn't bother in the C version.

Try your script with Width=2 and StackHorizontal(R,G,B,R,G,B,R,G) i.e. Total width=16 and StackHorizontal(R,G,B,R,G,B,R) i.e. Total width=14

With mod 4 widths the chroma is interpolated (blur), with others widths the chroma is PointResized (alias).

IanB

[WarpEnterprises]

Now do you mean the blurred version is the _OK_ one?

Why should there be a interpolation between adjecting YUY2-pairs?

[IanB]

Originally posted by WarpEnterprises
Now do you mean the blurred version is the _OK_ one?

Why should there be a interpolation between adjecting YUY2-pairs?Yes!

It really is about source material and user choice (There should be some here obviously, like with resizers [Point, Bilinear, BiCubic, Lanczos]). And this is why ConvertBackToYUY2() exists.

When playing with content that are images of the real world, interpolation is a great thing, who would use PointResize over Lanczos4Resize for there home movies.

However when working with computer generated block or line art (case here) PointResize maintains the impulse response transitions between polygons at the expense of getting aliasing and the transitions not being at the exact correct spacial co-ordinates, Lanczos4Resize however rings severely on this type of material (Stack up a grid of 90% and 10% 8x8 squares and LanczosResize it up and down about 30%, examine the output pixel by pixel)Let Cn=YUV(Yn,Un,Vn) and
Let Pn=RGB(Rn,Gn,Bn)

Yuy2 C1-Y2-C3-Y4-... -> ConvertToRGB() ->
RGB P1-P2-P3-P4-...

MMX code does this :-
R1=YUV2RGB(Y1,U1,V1)
R2=YUV2RGB(Y2,(U1+U3)/2,(V1+V3)/2) -- There is no U2 or V2!!!
R3=YUV2RGB(Y3,U3,V3)
R4=YUV2RGB(Y2,(U3+U5)/2,(V3+V5)/2)
....

C++ code does this :-
R1=YUV2RGB(Y1,U1,V1)
R2=YUV2RGB(Y2,U1,V1)
R3=YUV2RGB(Y3,U3,V3)
R4=YUV2RGB(Y2,U3,V3)
....IanB

[WarpEnterprises]

now I'm puzzled not a bit less.

1.: you mean AviSynth's ConvertToRGB switches between MMX and C++ depending on width mod4 ? (Ok, that's natural)

2.: your example seems a little bit difficult to read, so here is my try:

Pixel1 - Pixel2 - Pixel3 - Pixel4
YUY2 Y1U12 - Y2V12 - Y3U34 - Y4V34
RGB R1G1B1 - R2G2B2 - R3G3B3 - R4G4B4


My understanding so far was that there are different (more or less precise or suiting) ways to interpolate U and V "inside" the pairs P1/P2 and P3/P4 (for generating 6 values out of 4).

But if I understand you right there is a interpolation between e.g. P2 and P3?

[Wilbert]

I'm sure IanB will correct me if I'm wrong.


My understanding so far was that there are different (more or less precise or suiting) ways to interpolate U and V "inside" the pairs P1/P2 and P3/P4 (for generating 6 values out of 4).

You assume a wrong placement of chroma, the placement of chroma (YUY2) is as follows

Y1C1 Y2 Y3C3 Y4 ...

since a 1-2-1 kernel is used to interpolate it. So, it's not

Y1U12 Y2V12 Y3U34 Y4V34 ...

YUY2 -> RGB is given by

Y1C1 Y2C2x Y3C3 Y4C4x ...

with C2x = (C1+C3)/2, C4x = (C3+C5)/2, etc.

[IanB]

Hopefully Wilberts better explaination gets the point across.

Originally posted by WarpEnterprises
1.: you mean AviSynth's ConvertToRGB switches between MMX and C++ depending on width mod4 ? (Ok, that's natural)dI dunno about natural, but it's annoying when the 2 versions behave differently.

I'm just finishing refactoring Blur/Sharpen and some of the MMX tricks in there may be able to improve this as well.

Do people think there is a need for an option to select interpolation or point sampling? If I fix the MMX code then you won't be able to force the C code anymore by using width=(4xN)+2. Options are easy, speak up if you want it!

IanB

[Wilbert]

Do people think there is a need for an option to select interpolation or point sampling?
When would you choose point sampling? anime?

Btw, someone reported a bug about blur (I guess its in the avs 2.55 thread). Did you look at that?

[WarpEnterprises]

OK, thx, now I get it.
I was aware about the placement "between" P1 and P2, but not that this affects P3 (via the 1-2-1 kernel).

Did we discuss this in the past? I followed the colour sampling threads quite carefully (I thought).

And what do the other codecs/progs?
e.g. VD (at least my 1.4.10) does not smooth.
(AviSynth does in MMX since 1.05, I checked).

[scharfis_brain]

When would you choose point sampling? anime?

when doing some YV12 -> YUY2 -> YV12 conversions.

with pointsampling in both conversion processes (YV12-> YUY2 and YUY2 -> YV12) this chroma conversion is LOSSLES.

the current, smooth chroma conversion looks better, than point-sampling, but also smoothes the chroma. especially interlaced YUV420

[Wilbert]

Did we discuss this in the past? I followed the colour sampling threads quite carefully (I thought).
Sh0dan mentioned it a few times. Just search for kernel in avs forum :)

And what do the other codecs/progs?
e.g. VD (at least my 1.4.10) does not smooth.
Good to know about VD, dunno about codecs. My W2K can't boot atm, so I can't check anything.


when doing some YV12 -> YUY2 -> YV12 conversions.

with pointsampling in both conversion processes (YV12-> YUY2 and YUY2 -> YV12) this chroma conversion is LOSSLES.

the current, smooth chroma conversion looks better, than point-sampling, but also smoothes the chroma. especially interlaced YUV420
Might be a good idea to implement it and run some tests.

Btw, what about YUY2->RGB and pointsampling?

[scharfis_brain]

imo, all colorspace conversion routines should have a customizable sampling method (linear, point, whatever...)

also I really wish to have something like:
assumeYV12()
and
assumeYUY2()


those functions should enlarge or shrink the chroma-planes without caring about their content.

I request this, cause yesterday, I tried to extract the native interlaced YV12 from a DV-AVI, which had been upsampled to YUY2 by the codec using point-sampling.

my current script looks like this:

avisource("jaggietextcheck.avi") # the video is delivered as YUY2

extract y, u and v
x=last
u=x.utoy()
v=x.vtoy()

#now, reduce the vertical linesin this way: from lines 0, 1, 2 and 3 select lines 1 and 2
# for maerging them to a YV12 plane, a unnessecary conversion to yv12 is needed.
# instead an assumtion would be totally sufficient!
u=u.separatefields().separatefields().selectevery(4,1,2).assumefieldbased().weave().converttoyv12()
v=v.separatefields().separatefields().selectevery(4,1,2).assumefieldbased().weave().converttoyv12()

ytouv(u,v,x.converttoyv12())

so, instead of converttoyv12 a assumeyv12() would be (speed-wise) much better, cause for those operations, the chroma planes may be destroyed without any harm.