Colourspace conversions

[mustardman]

I have heard it mentioned on this forum that repeated colourspace conversions will degrage quality. So, a question to those in the know...

Any conversion to RGB will be lossless, however conversion from RGB back to anything else will be lossy?

And, is there a guide on colourspace parameters and their limitations. For example, YV12 can only operate modulo 2, wheras RGB is free in this regard. Does YV12 use 2x8bit Luma + 1x8bit chroma to represent an encoded "group", and is this 1x2 (vertical) or 2x1 (horizontal), or indeed is it even further confined to 2x2?

There seem to be quite a few differnt colourspaces available, but is there some real information on what each is, and where it should be used?

Also, quite a few AVISynth 'functions' expect a particular colourspace, I assume this is for speed reasons? but it does raise the prospect of a string of functions having to do multiple colourspace conversions?

[sh0dan]

(moving to development)

I'm not sure I get all your questions. I will however try to do a quick overview.

Two things matter in conversions:

- Color representation (RGB vs. YUV)
- Subsampling (YUY2 vs. YV12)

Color representation _cannot_ be changed without loosing precision. That means an RGB<->YUV conversion will always be slightly inprecise. Maybe offsetting one of the components by one or two due to rounding.

Subsampling is for speed, and saving storage space. A subsampling will of course lead to loss of data, as chroma precision isn't as good. Changing between different subsamplings will also lead to blurred chroma, as chroma is interpolated on all upsampling.

For more technical data see DataStorageInAviSynth (http://www.avisynth.org/index.php?page=DataStorageInAviSynth) and ColorSpaces (http://www.avisynth.org/index.php?page=ColorSpaces) at avisynth.org - or search the forum.

In short: Don't convert between colorspaces. Selecting the correct colorspace depends on input and output format and application.

[trevlac]

I'm a bit of a newbie to all of this, but I have done a lot of reading recently. I'd like to add more detail if I could.


-------------------------------
It is probably best to seperate out a few concepts in order to understand digital color.

1) Color calculation - This seems to be the traditional use of the term 'colorspace'. Colors are represented by a combination of components. Common components 'groups' for digital seem to be RGB, YCbCr (often referred to as YUV), and CMYK (cyan magenta yellow black). For example, equal parts R + G + B give you a color ranging from black to white, using an RGB calculation. For a YCbCr calc, the value of Y represents black to white.

2) Precision of components (channels) - If you limit each RGB (or YCbCr) component to values between 0 and 255, you limit the number of colors you can represent. To be precise, 8-bit components can represent 256(R) * 256(G) * 256(B) = 16M+ colors. Because, Y,Cb,Cr components are not the same as RGB components, a YCbCr value may represent a color not in the RGB space. Also, 'normal' YCbCr colors do not have the full range of 256. Y has 220 values and CbCr each have 225 values.

3) Subsampling - Some smart person figured out we don't see color as well as B&W. Hence color difference color spaces were born. YCbCr is an example. So is YUV and YIQ which are both used in analog. For YCbCr, you can share the CbCr across pixels and not lose much for normal viewing. For editing, the lack of info can be a problem. For example, blue screen techniques would be difficult because the edge would show. As you can see, subsampling still keeps the full range of colors, but limits the required bandwidth/space. Things like 4:4:4, 4:2:2, 4:2:0 describe which pixels share. YUY2 is 4:2:2 which means 2 pixels share horizontally. YV12 is 4:2:0 which means pixels share horizontally and vertically. The vertical share is why knowing if YV12 is interlaced is important

4) FourCC codes - YUY2 and YV12 are codes that tell you how the data is stored. Some use the same subsampling and color space, but just store the data in a different order. I believe UYVY is 4:2:2 YCbCr just like YUY2.

------------ given all that


Any conversion to RGB will be lossless, however conversion from RGB back to anything else will be lossy?

YCbCr 8-bit (range 16-235) to RGB 8-bit (range 0-255) will cause colors to shift by a small amount. Technically, the calculations to convert give you numbers like 191.587. This would round to 191. If you then converted back, you may not get the same color. So any conversion is lossy. By how much is the question. A little know fact is that YCbCr can contain data outside of the normal range. Most conversions to RGB just truncate this data. At a minimum, one should correct this back to the normal range before converting.



And, is there a guide on colourspace parameters and their limitations. For example, YV12 can only operate modulo 2, wheras RGB is free in this regard. Does YV12 use 2x8bit Luma + 1x8bit chroma to represent an encoded "group", and is this 1x2 (vertical) or 2x1 (horizontal), or indeed is it even further confined to 2x2?

The limits you speak of are due to subsampling. These effect YCbCr spaces because they are subsampled. Another limit is that YCbCr can represent colors that are not valid for RGB. The conversion calculations would create negative numbers. Another limit is that certain colors would be clipped when run thru an analog system. For example 'over saturated' yellow or red. If you start with normal video and do not muck with the colors much, these may not be a problem.


There seem to be quite a few differnt colourspaces available, but is there some real information on what each is, and where it should be used?

Some links:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwmt/html/YUVFormats.asp
http://www.slashcam.com/directory/Knowledge_Basics-Color_models.html


Also, quite a few AVISynth 'functions' expect a particular colourspace, I assume this is for speed reasons? but it does raise the prospect of a string of functions having to do multiple colourspace conversions?

A string of conversions would be slow. They would also change the colors, possibly reducing the number of colors (tonality). As sh0dan said, don't convert.

I'd say, limit your conversions, and know your converters; but I do not have a lot of experience in seeing the results. There are also clearly, good conversions and not good conversions. For example, converting YCbCr with data outside of the normal range (like a capture with the contrast too high) to RGB will most likely kill your whites. Some YCbCr to RGB converters may also use the HD converion calcs. These will definately cause the colors to shift. BTW: Codecs have built in converts and windows specifies a default converter.

Some conversions are going to take place regardless of what you do.

For example: Capture an NTSC TV show to DVD.

Camera(RGB)->Edit(??)->Transmission(YIQ)->Capture(YCbCr 4:2:2)->Edit in VDub(YCbCr 4:4:4 ->RGB)->Encode to Mpeg(YCbCr 4:2:0)->Play from DVD Player(YIQ)->Show on TV(RGB).