problem with weave()

[mathmax]

Hello

I noticed something weird with the function weave(). Let me introduce the issue.

First, I'll weave these two fields (I applied a pointresize() to stretch the lines vertically):
http://img825.imageshack.us/img825/6283/t0000l.jpg
+
http://img710.imageshack.us/img710/619/b0000.jpg
=
http://img52.imageshack.us/img52/5112/wtb0000.jpg

so far so good... the result is just as we expected.

Now, I'll weave the two following fields (I volontarily changed the hue of the top field in order to keep its trace).

http://img715.imageshack.us/img715/9007/e0000.jpg
+
http://img39.imageshack.us/img39/8807/o0000.jpg
=
http://img821.imageshack.us/img821/2486/weo0000.png

The result is already more surprising. If you zoom in, you'll notice that the hue doesn't change line after line but every two lines !!

Finally I'll stack the two first examples and see what happens (I applied a pointresize() to stretch the lines vertically and I selected only a small part of the video):

Btw, please notice that overlay() doesn't make a clean job hear.. the overlayed video smears on the one underneath.
http://img600.imageshack.us/img600/1934/te0000.jpg
+
http://img593.imageshack.us/img593/2600/bo0000.jpg
=
http://img850.imageshack.us/img850/5127/wtebo0000.jpg

Why are the colored lines messed up ?? I mean, why don't I get the same result as example 1?

If I convert to RGB before weaving, the result is better (the lines are colored one by one and not two by two).. but the colors are still alterd:

http://img715.imageshack.us/img715/1214/weorgb0000.png
Should I always convert to RGB before weaving? Am I using the good matrix (ConvertToRGB32(matrix="Rec601"))?

I would really like to understand what happens... here is the script I used:


src = avisource("src.avi").trim(4,5)
t = imagesource("redlines.bmp")
b= imagesource("bluelines.bmp")
e = src.selectEven().overlay(t, 0, 100).crop(0,94,-0,16)
o = src.selectOdd().overlay(b, 0, 100).crop(0,94,-0,16)
interleave(e, o)
AssumeFieldBased()
AssumeTFF()
weave()
PointResize(720, 320)

[Didée]

Most of the confusion comes from the fact that you weave YV12, but view the final result (in Vdub, probably?) as RGB. Since Vdub (or whichever app you're using) does not "know" that the input is interlaced, it does a progressive YV12->RGB sampling. This is wrong in the given case, of course.

==> Add a "ConvertToRGB(interlaced=true)" to the end of your script.

The PointResize in your script is misleading, too. That's a "progressive" resize, assuming progressive layout of chroma samples, where the video in fact is interlaced. For purposes of zooming to better see the fine structure, you can do the resize after the RGB conversion, but not as long as the video is YV12i.

[mathmax]

@Didée

If I do :
src = avisource("restore.avi").trim(4,5)
t = imagesource("top.bmp")
b= imagesource("bottom.bmp")
e = src.selectEven().overlay(t, 0, 100).crop(0,94,-0,16)
o = src.selectOdd().overlay(b, 0, 100).crop(0,94,-0,16)
interleave(e, o)
AssumeFieldBased()
AssumeTFF()
weave()

ConvertToRGB(interlaced=true)
PointResize(720, 320)

I get exactly what I posted above:
http://img715.imageshack.us/img715/1214/weorgb0000.png
≠
http://img52.imageshack.us/img52/5112/wtb0000.jpg

the colors are still altered.. :s



Since Vdub (or whichever app you're using) does not "know" that the input is interlaced, it does a progressive YV12->RGB sampling. This is wrong in the given case, of course.
how can I say to Vdub that my source is YV12 interlaced? I guess I shouldn't convert to RGB each time I weave, should I?

[Didée]

how can I say to Vdub that my source is YV12 interlaced? I guess I shouldn't convert to RGB each time I weave, should I?
If you plan to encode through Virtualdub, in "fast recompress" mode, then conversion to RGB is not necessary. Just tell the encoder to work in interlaced mode.

For visual inspection in Vdub's video panes, you must convert.


It seems the image bmp's you're using consist of one-pixel color stripes? Such is not possible in YV12.


Edit - Just got aware of this:
Btw, please notice that overlay() doesn't make a clean job hear.. the overlayed video smears on the one underneath.
No surprise either. The source video is YV12, the BMPs are in RGB. Overlay does an internal conversion (everything is converted to YUV 4:4:4), does the overlay, then everything is converted back to the format of the primary input (the YV12 video). Hence the RGB stripes get smeared, because 1-pixel-colorstripes are not reproducible in YV12.

In the initial example with just the colorstripes, everything was working in RGB format (probably), that's why the result was clean.

Everything you did in combination with the video file was restricted by the subsampling of YV12, resp. interlaced YV12.

It seems you're not quite saddle-fast in that area. :)

(There's no disgrace in that - it took me years to finally get it. Everytime I thought "ah, NOW I got it!" ... it took only little time until scharfis_brain came along with something, and it revealed that I still got sth mixed up.....) :D

[mathmax]

Thank you for the explanation :)
Indeed, I'm still still not at ease with the color formats.. and it might be a stupid question but I wonder why is it impossible to have a one-pixel color stripe in YV12..

If that is not possible to have one-pixel color stripe in YV12, then I guess it's not possible to have this:
http://img268.imageshack.us/img268/1979/rgb0000.png

instead, we would always have this:
http://img703.imageshack.us/img703/3604/yv120000.png

this is strange.. that would mean lines are colored two by two in YV12?

[Gavino]

I wonder why is it impossible to have a one-pixel color stripe in YV12.
YV12 uses chroma subsampling.
There is only one chroma sample (pixel) for every two luma samples in both the horizontal and vertical directions, so a YV12 clip must have an even width and height.

For more details, see http://avisynth.org/mediawiki/Sampling.

[Didée]

Short facts (regarding vertical chroma resolution)
- one YV12 chroma sample carries information for 2 vertical output pixels

Progressive frame:
- chroma sample#1 is responsible for (luma) scanlines 1+2 , sample#2 is responsible for scanlines 3+4 , etc.

Interlaced frame:
- chroma sample#1 is responsible for (luma) scanlines 1+3 , sample#2 is responsible for scanlines 2+4 , etc.


Do not look at this post or thread (http://forum.doom9.org/showthread.php?p=1036052#post1036052). It is confusing. :D

[mathmax]

So if I understand well, a pixel carries the chroma information for 4 pixels (both horizontal and vertical direction), right?

If the chroma can't differ between these 4 pixels, that means the conversion to YV12 must be very lossy.. :-/

There, in a weak moment I was assuming that pairs of even/even pixels, sharing "the same color", would get weaved with odd/odd pairs of pixels, also sharing (another) same color. If it were so, static chroma would appear combed, or stairsteppy like 4:0:0.
Here, you must be mentioning the problem I have because vdub has no mean to know my source is interlaced.. What do you mean by "4:0:0"?

Is there really no way to tell vdub that the source is YV12 interlaced.. I mean, should I necessarily convert to RGB in order to visualize?

[Robert Martens]

If I remember correctly, I believe it's been mentioned on these boards that VirtualDub follows the hardline technical definition of YV12, which is strictly progressive; there are video specs which include both interlacing and 4:2:0 subsampling, but the name "YV12" refers exclusively to a progressive format, and the existence of "interlaced YV12" in Avisynth is merely a convenience for users. The mathematical representation of color is not one of my strong points, but I'm almost certain I've heard this characteristic of VirtualDub described in the past.

As far as I know, there's no way to tell VDub to read your chroma properly, but you can do it in AvsPmod (http://forum.doom9.org/showthread.php?t=153248). Right click the preview, and under YUV->RGB you can set progressive/interlaced, along with your preferred coefficients if the default doesn't suit your clip.

[Gavino]

If I remember correctly, I believe it's been mentioned on these boards that VirtualDub follows the hardline technical definition of YV12, which is strictly progressive
For example, see the last part of this post (http://forum.doom9.org/showthread.php?p=1482560#post1482560) (and the links it contains), as well as the discussion following it.

[mathmax]

For example, see the last part of this post (http://forum.doom9.org/showthread.php?p=1482560#post1482560) (and the links it contains), as well as the discussion following it.
Why don't they fix this ? Most of the DVD are YV12 interlaced...

I feel difficult to understand the relevance of this format. One pixel should carry the chroma information for 4 pixels.. that is a very lossy way to store data, isn't it?

[Gavino]

Why don't they fix this ? Most of the DVD are YV12 interlaced...
If you read the links I gave, you'll see they don't regard it as a 'bug', so no need for a 'fix'. VDub doesn't read DVDs, so it's only a problem with Avisynth scripts, and Avisynth's definition of 'YV12' to include interlacing.

I feel difficult to understand the relevance of this format. One pixel should carry the chroma information for 4 pixels.. that is a very lossy way to store data, isn't it?
Most video compression is lossy in some way. Chroma subsampling is a sensible way to compress video data, since the human eye is less sensitive to changes in colour than to changes in brightness.

[mathmax]

Thank you Gavino for the explanations.
I just don't understand what the terms 4:2:0 (or 4:0:0) subsampling mean..

[Guest]

I just don't understand what the terms 4:2:0 (or 4:0:0) subsampling mean..
4:0:0 is a representation with only the full luma resolution, i.e., monochrome.

4:2:0 is a representation with full resolution for the luma and half resolution both vertically and horizontally for the chroma.

4:2:2 is a representation with full resolution for the luma and half resolution horizontally for the chroma.

4:4:4 is a representation with full resolution for the luma and the chroma.

[nhope]

I'm wondering if this might be related to the errors I get when I weave YV12 (http://forum.doom9.org/showthread.php?p=1498044#post1498044).

[pandy]

Thank you Gavino for the explanations.
I just don't understand what the terms 4:2:0 (or 4:0:0) subsampling mean..

Then You should read this:
http://www.hometheaterhifi.com/the-dvd-benchmark/179-the-chroma-upsampling-error-and-the-420-interlaced-chroma-problem.html