About colorspace (RGB <->YUV) conversion argument

[KingJeremy]

So far it is clear that conversions from an original RGB24(24bit color info) or RGB32(24bit color info + 8bit alfa info) format to YUY2 4:2:2(16bit color info) or YV12 4:2:0(12bit color info) is lossy.

BUT is there really any change in color info when our original file is in YV12 or YUY2 format and we convert it to RGB24 or RGB32 while some processes and come back to its original color format?

In my opinion it shouldn't have any effect else than the process times since the RGB24 or RGB32 colorspace covers all the colors in YUY2 and YV12 colorspace (so I think there won't be any loss or change in the color data because of the conversion).

For a more clear statement if I have a mpeg2 file from a dvd and rerender it with lower bitrates even I use RGB colorspace conversion while the process it won't have any effect (loosing or changing) the colors in the file but the process time will take longer.

Can anyone confirm the above statements if I'm right or wrong.

[hanfrunz]

Hi KingJeremy,

there are a lot of yuv-values which can not be converted to rgb!

for example: y=32, u=32, v=32
if you convert it with this formula:

r=1.164383*(Y-16)+1.596027*(U-128)
g=1.164383*(Y-16)-0.812968*(U-128)-0.391762*(V-128)
b=1.164383*(Y-16)+2.017232*(V-128)

you get r=-134,59(!!), g=134,31, b=-175,02

if you convert r=0, g=134 and b=0 back to yuv you get y=84, u=79 and v=89...

you see the problem?

hanfrunz

[KingJeremy]

Just because lack of my knowledge about this subject I'd like to represent a statement form a document form matrox's site
http://www.matrox.com/video/products/pdf/canopus_got_it_wrong.pdf on page 13 it says:

We all agree that when you import a native RGB image into a YUV project, it will lose color resolution. If you think of YUV and RGB color spaces as 3D volumes, it is clear that pouring the contents of a largeglass (RGB) into a smaller glass (YUV) causes some of the original contents to be lost. This is NOT however what happenwhen DV (YUV) video is processed in the RGB space. If you start with YUV video, process it in RGB with a bigger dynamic range, then return to YUV, nothing is lost provided a high quality conversion algorithm is used. Looking at the 3D volumes again, we can see that when pouring the contents of a small glass (YUV) into a larger glass (RGB) you do not lose anything, you just have a lot more room to stir. When you pour the contents back to the small glass (YUV), again nothing is lost.
What is the accuracy of such a statement?

[hanfrunz]

Hi KingJeremy,

have a look at
http://techpubs.sgi.com/library/manuals/3000/007-3524-001/pdf/007-3524-001.pdf

on page 84 (pdf page 102) you see it's the other way around! Matrox is talking about color resolution, but i am talking about the greater colorspace!

"Figure D-1 shows the RGB color cube inside the CCIR color space. The volume contained within the outer (CCIR) cube, but outside the inner (RGB) cube, represents “illegal” colors that cannot be displayed."

But, if and only if the YUV-data has NO illegal colors, then Matrox is right, because you can represent a colour with full 3 byte (color resolution is better).

But the yuv-colorspace (gammut) is bigger!

hanfrunz

[nuked]

I've been wondering about this type of issue a bit.. all these filters in diferent color spaces and everyone saying the conversions are lossy. It seems unecesary.. As stated abouve.. asuming the space cover the same color space volume, then the only issue is rounding and if you convert to a color space with more bits then you keep some extra ones to avoid rounding errors and there should be no error.

Even if some colors can't be representented in a physical way though.. with the right ultra-color space they could still be represented even it required negative values. This could be great for interim processing even if it can't be displayed. Convert to this megaspace with a few extra bits for everything... do all your processing, and then convert back with no rounding error. Ok filters would be a bit slower.. but seems like for those who want quality this would be great. Probably even get better results than running all your filters in yv12... because even doing this will have rounding errors in every filter that add up... by keeping extra bits.. you only get one rounding error at the end.. I mean we all learn this when we learn to use calculators in high school or well before... keep extra bits and round back at the end. If you did the calculations by hand it would be sedcond nature to it that way. In fact, I've heard on threads here that dvd shops basically do this.. they work in spaces with extra bits. The conversion loss issue whith such a mega color space is resizing... probably best to have a filter that interpolates your resized yv12 values directly from the megspace to avoid interpolating twice in order to reduce color plane resolution. Probably best to resize last if possible since going to yv12 is effectively a color resize anyway.

You could have 2 of these ultra-spaces... one rgb and one 4:4:4-like YUV(but more bits) and switch between them several times depending on ease of programming and speed for diferent filter types. With enough extra bits.. even after several switches the rounding errors would still be below the level of presiscion of the final space you'll convert back to. This business of restricting calculations to the same space used for display seems , well maybe fast... but well, restrictive. Am I missing something?

On a side note... as for colors that can't phyiscally be displayed... even though I've alrady showed why it's nto an issue for this purpose.. I still think it's kinda silly issue. In the end everythign shows on a tv or monitor that physically works in rgb.. If a value is unphyiscal in a such a space then it should be illegal.. YUV spaces are a mathematical construct anyway.. a transformation from the info given by all physical io devices. If a value is not directly mappable from such a physical device, it should be illegal. YOur transformation doesn't even make sense.. and that's the point.. it's not well defined for such colors.. how do say what the brightness of that rgb thing you created is? You can't. YOu can use some equation for brightness.. but it obvously doesn't physically apply here. That means the transformation itself is meaningless and you can't even say these are the correct equations in that range.. because the correct equations produce the corret brightness. The transformation is simply undefines for these valuse. If there is no definition for how to transform between certain values and a physicaly viewable image.. then your values are utter nonsense in the first place. After all... a color space is supposed to describe colors.

edit: if at this point you want to transplant this over to avisynth that's more than fine by me.

[nuked]

by the way.. what's up with those weird transformation equations? The ones shown in this thread are a translation followed by some kind of matrix transformation. This seems very strange and indeed unphysical. like 0 0 0 doesn't even trasform to 0 0 0. Seems odd to me, so I did a quick google search and came up with this:

http://www.eetasia.com/ARTICLES/2001MAY/2001MAY09_DSP_CT_AN1.PDF

look on page 13& 14 and you see something like what I expect... a simple matrix transformation from RGB to YUV. If the translation is just implemented in this particular case for some weird reason.. like to reserve lower bits for some other usage or something strange like that(edit:this doesn't seem like what's happening either.. cause those equations aren't really a bit shift.. are they even correct?) then of course some values will be unphysical and they should not be used.

With a simple matrix transformation and reasonable color spaces I don't see why all transformations can't be nice and unitary and well defined for all values... but I don't know enough about the details yet.

Anyway.. I still want to know what people think about a space with more bits for processing.

edit: Ok.. I get it now.. green corresponds to negative U and V values. In the actual implementation all positive numnbers are used but the origin is offset... so zero in U and V isn't grey.. it's green.(but maybe not perfectly green)
Anyway.. none of this changes the point.