4:1:1 to 4:2:0 colorspace conversion

[fmctm1sw]

Colorspace is something that has confused me for a long time. I know converting between colorspaces is generally not a good thing but I am particularly interested in 4:1:1 to 4:2:0. 4:2:0 seems to have an odd scheme of putting color information between a group of four Y samples. How does it do this? I realize I'm losing color information when going from TBC (as soon as I get a power supply for it) at 4:2:2 to ADVC-50 at 4:1:1. But it's the conversion to 4:2:0 that worries me. I also now need to have a converttoyuy2() in my avisynth scripts whe I use my ADVC-50. What is that conversion doing? I've seen illustrations of how this works, and I know graphically how these colorspaces are presented. Are there any illustrations anywhere of what actually goes on during a conversion?

[edDV]

We were discussing this over here.

https://www.videohelp.com/forum/viewtopic.php?t=268544

but I guess this qualifies as a separate topic. I'll repost my comment from over there and we can apply it to your issue.

"4:1:1 like 4:2:2 keeps the chroma pixels in line with the first luminance sample. This results in quarter H sampling but full V sampling of chroma.
http://www.quantel.com/domisphere/infopool.nsf/HTML/dfb411?OpenDocument

4:2:0 is optimized for 2D display but the difference to the viewer is minimal. 4:2:0 results in half sampling H and half sampling V. In theory this averages the chroma resolution in H and V.
http://www.mir.com/DMG/chroma.html

4:2:2 and 4:1:1 pixel alignments are/were used during production because pixel location is more predictable during 2D and 3D spatial manipulation. Maybe this concept is obsolete. "

Now what you are doing is rearranging chroma pixel locations in the raster. 4:2:0 and 4:1:1 to 4:2:2 and back are probably the biggest issues but this is all in YUV scaling space. Y is safe.

Some h&v spatial errors in chroma are no big deal IMO but any conversion to RGB scares me big time. The eye doesn't respond much to chroma resolution (UV). Any conversion to RGB and back will intoduce these errors into the luminance which will be an order of magnitude more visible. We are hunter animals and our eye is highly sensitive to resolution and motion in monochrome.

[fmctm1sw]

Yeah, that thread is what got me thinking about it again. I guess what I am worried about is information being "made up" when these conversions are being made. I was especially worried about 4:2:0 since the location of the color information is moved. Hopefully, not too much is being guessed at in these conversions. Agreed, I avoid RGB colorspace converisons like the plague...

[edDV]

Yeah, that thread is what got me thinking about it again. I guess what I am worried about is information being "made up" when these conversions are being made. I was especially worried about 4:2:0 since the location of the color information is moved. Hopefully, not too much is being guessed at in these conversions. Agreed, I avoid RGB colorspace converisons like the plague...

Small h&v chroma pixel movement shouldn't be a huge issue. Best to test compare the output against the input with full motion and stop motion to see if you see a difference.

[edDV]

...
I guess what I am worried about is information being "made up" when these conversions are being made.

I'm not sure how a 4:2:2 device would treat a 4:1:1 or 4:2:0 source, especially in a consumer product. I'm sure the problem has been solved in broadcast equipment because they deal with DV material all day. The goal would be to make 4:2:2 equipment either transparent or at least output correct data for 4:1:1. Maybe somebody knows the drill.

[vhelp]

I find it troublesome to discuss 422 and higher (444) because of
the lack of source files to work with and test. As I have seen
it, there are currently no sources (within easy grasp) of getting
a hand on 4:2:2 source (MPEG) from any mediums (ie, dvd; cable;
satellite; laserdisc; etc) as such, it's hard to talk about it
when you can't work with an actual source file.
And even if you could *record* in 422, it would not be the same,
for it is fake, because the color information is not there, rather
certain attributes are redistributed to look (or fill) in the area
that *should* be occupied by *TRUE* 422 data. Anyways.
.
I realize there are containers (avi) that save to 422 (ie, huffy)
but that is not enough because in reality, the source is not a
*TRUE* 422 source. Its just a 420 rapped inside a 422 container
(ie, huffy) and therefore, any tests done on (shall I say) fake
sources (or, replicas) are invalid at best.

TMPGenc has the feature to encode mpeg to 422, but at the expense
of no software (nor dvd player) to play them. But still, it's also
fake, because the color space is not a true 422, just a 420 (or 411
from DV sources) again, rapped inside a 422 container (only this
time, its an actual MPEG-2 container [stream])

Regarding Huffy ...

Last I read, it saves in 422 samples. I'm not sure if this is true,
but I'm operating under the assumption that it is, (or can be set)
as such.

-vhelp 3342

[Donny661]

Isn't Beta a 4:2:2 source? I think I've seen that mentioned on a few threads. Perhaps if you could get your hands on a Beta tape (idealy commercial recording) and player, you could do any tests you would want with it. But then again . . . you would probably want to make sure somehow that the capture device/card you are going to use is truly 4:2:2 capable too.

[fmctm1sw]

I've thought about this over the last couple days. I think where I'm getting hung up is the illustrations used to describe this. If a pixel is, by definition, the smallest individual addressable element of frame/field then it is theoretically impossible to place chroma information "between" them. I don't believe the illustrations are to be taken literally. The answer probably lies within the sampling frequencies that are used. I guess I should stick to good old fashioned "try it and see what happens." Not understanding it bothers me though...

[Wilbert]

I've thought about this over the last couple days. I think where I'm getting hung up is the illustrations used to describe this. If a pixel is, by definition, the smallest individual addressable element of frame/field then it is theoretically impossible to place chroma information "between" them. I don't believe the illustrations are to be taken literally.

The chroma placement between luma samples (but also 'next to' the luma samples for YUY2 or any other color format) indicate the weights used for sampling.

If you want to play a clip it should be converted to RGB (because displays are RGB), so some YV12->RGB conversion is done. The chroma placement indicates the corresponding weights. See also

http://www.avisynth.org/Sampling

Look up the ' YV12 progressive conversion -> YUY2' and 'YUY2 conversion -> RGB' conversions, those are the most easy to understand (at least i hope ).