Color correcting using component out of video card

[T-Bone]

I have asked a number of color space questions before, and here is another one.

I have a Radeon 9800 Pro (AGP) video card in an older system with a Storm card (no component out). For $20, I can buy an adapter that plugs into the DVI-I connector on the video card and gives me YPbPr (analog YUV) out to my monitor.

I'm guessing this thing is this simple because the 4 analog pins on the DVI-I out of the card are hot, but how this thing works is a question for another day.

The question here is whether I get proper colors out of edius to my monitor with this setup. IOW, if I take the same material in edius and output it to the same monitor, will the colors be the same whether I:

(a) go out of this video card with this $20 adapter, or

(b) go out of a Storm/NX card analog component out?

Comments about other reasons to get an NX card are fine, but what I'm really interested in are the colors, since that has always been the biggest difference between going out of a Storm/NX card versus going out of a regular video card without any adapters.

[GrassValley_KH]

A Graphics card, output to a monitor, will be an RGB-as-YUV representation of the video overlay.

A Storm/NX card, output to a monitor, will be a true YUV representation of the source video (on the timeline).

As such, if you are a stickler for accuracy (this is important if you plan to have your work on Broadcast Television), you need to take this into account.

Not all YUV component, is.

[T-Bone]

Not all YUV component, is.

My understanding from this article http://en.wikipedia.org/wiki/YCbCr is that there are standard conversion factors for going from RGB to YPbPr, meaning that, to make up Y for example, you take specific percentages of each of R, G and B.

Are you saying that is not as easy as it sounds, and that there are different ways to accomplish it, so that the NX can do a better job of doing that conversion as compared with how ATI might do the conversion?

[GrassValley_KH]

I guess the point I am (always) trying to make, is that when you choose to color correct a video overlay mirrored from a graphics card, you're correcting an interpretation of RGB data represented as YUV. Along the way, concessions have to be made - RGB->YUV is not a bit-for-bit calculation.

Now, that said, the codecs we (and other vendors) use, are YUV-based. As is our hardware, for output. So there's no RGB-YUV "flipping" and the results you see on a tv screen (such as a broadcast monitor), are the real deal.

As I said, this is really only an issue for people looking for the most accurate image information/data to work with. For others, they're happy with a "cheap" solution that merely involved mirroring their graphics card's overlay.

But be wary of Broadcast stations - they can be very particular when it comes to colours and legality.

[GrassValley_BH]

Are you saying that is not as easy as it sounds, and that there are different ways to accomplish it, so that the NX can do a better job of doing that conversion as compared with how ATI might do the conversion?

For SD there are actually two defined methods of going from RGB to YUV. One method assumes 0-255 RGB maps to 0-255 YUV. The other assumes 0-255 RGB maps to 16-235 YUV.

That difference alone can make for a non-WYSIWYG experience.

Beyond that, the gamut (color range) of YUV is different from RGB, much like how the gamut of RGB is different from CMYK. Conversion can change what you get.

Further reading:

http://en.wikipedia.org/wiki/YUV

http://www.poynton.com/notes/colour_and_gamma/ColorFAQ.html

[T-Bone]

Kenneally (whoops!, I see BH has responded, too), just one more follow up.

So edius sends a YUV to the video card, then the video card converts it to RGB just like it converts everything else it receives from any other program, then all this $20 ATI adapter does is some simple represenation of the RGB as YUV, and that YUV is not the same as the YUV that edius sent to the video card.

A theoretical alternative, which you're saying does not happen, is this: the YUV that edius sends to the video card does not get converted to RGB and just passes straight through as YUV (after a digital-to-analog conversion) on the analog pins of the DVI-I connector.

[Timo]

you can find some informations about colorspace-conversion here

Enjoy.....

[T-Bone]

thanks, timo, I have read several articles on the subject, but not that one

that's my ultimate question, I guess, whether there is any color space conversion happening going from edius through the video card and adapter to the monitor

[GrassValley_KH]

A theoretical alternative, which you're saying does not happen, is this: the YUV that edius sends to the video card does not get converted to RGB and just passes straight through as YUV (after a digital-to-analog conversion) on the analog pins of the DVI-I connector.

This could be possible, if we decided to write a device driver for ATI, which in turn would feature an EDIUS hardware profile (like DVStorm, NX, etc). But, as I am sure you will agree, is not going to happen. We make our own boards that give you YUV output, after all.

[T-Bone]

OK, the device driver is the link I have been missing - understand, thanks

[Timo]

Hi Kenneally,

what about the possibility of HDMI-connectors?
;-)

[GrassValley_KH]

Same sort of deal again. A device driver has to be written - if it's a graphics card, the problem gets much larger, because of the volitile nature of GPU lifecycles and development.

It is easy for a company like Matrox to do this because they manufacture a software plug-in for an established NLE, and make graphics cards/chipsets.

Last I checked, Grass Valley don't manufacture GPUs, nor do they plan to.

If it was a separate HDMI output board (e.g. Blackmagic Intensity), then it might be a little easier (because technically the board is only designed to work with YUV data).

PS. Good to see you here Timo! Wie Gehts?

[T-Bone]

es geht mir gut

[Timo]

If it was a separate HDMI output board (e.g. Blackmagic Intensity), then it might be a little easier (because technically the board is only designed to work with YUV data).

this is what i´m thinking about

nor do they plan to.

:(

Off topic:
I had a good trip back, after visiting a couple of national parks near Vegas. Impressive !
If you travel to germany, let me know :)

[peterC]

I guess the point I am (always) trying to make, is that when you choose to color correct a video overlay mirrored from a graphics card, you're correcting an interpretation of RGB data represented as YUV. Along the way, concessions have to be made - RGB->YUV is not a bit-for-bit calculation.

Now, that said, the codecs we (and other vendors) use, are YUV-based. As is our hardware, for output. So there's no RGB-YUV "flipping" and the results you see on a tv screen (such as a broadcast monitor), are the real deal.

As I said, this is really only an issue for people looking for the most accurate image information/data to work with. For others, they're happy with a "cheap" solution that merely involved mirroring their graphics card's overlay.

But be wary of Broadcast stations - they can be very particular when it comes to colours and legality.

I am having trouble coming to terms with an adequate output LCD monitor from YUV.

If you go S/composite or RGB/component to a computer LCD monitor 1900 x 1200 say, what are you seeing? True YUV or an RGB / progressive interpolation?

I can't get a clear answer on this. CRT is dead n decent affordable LCD is the answer.I've seen TV station Panasonic LCD's used that top $ was paid for that u wouldn't use in fit. Hopeless!!

Any suggestions? I can only see hi-res computer monitors as an answer, but progressive vs interlaced n YUV vs RGB has got me stumped.

Love to hear of an accurate affordable solution that somebody's using that is 'technically correct' and reasonable in cost.