Correct YUV to RGB conversion

Hi there,

I want to convert the 10bit YUV signal to RGB (10bit). I know that I can do this with the ConvertFrame method but this would need to parse the results as they are packed in 32bit (bmdFormat10BitRGB). I actually copy them directly to a 32bit per channel surface. So I need to do the conversion on my own.

I found a lot of different YUV to RGB algorithms but they don't seem to work properly. Does anyone know the correct conversion? The wiki algo for BT709 doesn't seem to be correct.

Any help is highly appreciated,
Jens

I have the following on the last page of the Decklink SDK:

2.7 Formulas
Color space Conversion Formulas
The following basic equations convert between gamma-corrected RGB and YUV colour spaces.

SD RGB to YUV conversion
Y = 0.257R + 0.504G + 0.098B + 16
Cb = -0.148R - 0.291G + 0.439B + 128
Cr = 0.439R - 0.368G - 0.071B + 128

HD RGB to YUV conversion
Y = 0.183R + 0.614G + 0.062B + 16
Cb = -0.101R - 0.338G + 0.439B + 128
Cr = 0.439R - 0.399G - 0.040B + 128

SD YUV to RGB conversion
R = 1.164(Y - 16) + 1.596 (Cr - 128)
G = 1.164(Y - 16) - 0.813 (Cr - 128) - 0.391 (Cb - 128)
B = 1.164(Y - 16) + 2.018(Cb - 128)

HD YUV to RGB conversion
R = 1.164(Y - 16) + 1.793(Cr - 128)
G = 1.164(Y - 16) - 0.534(Cr - 128) - 0.213(Cb - 128)
B = 1.164(Y - 16) + 2.115(Cb - 128)

Ensure that output values are clamped to keep them in the 0 - 255 range. The valid SMPTE ranges are Y: 16-240, Cb/ Cr: 16-235.
IDeckLinkOutput::DisplayVideoFrameSync or IDeckLinkOutput::ScheduleVideoFrame can convert RGB formatted frames to YUV for output.

I've also found external libraries like OpenCV and IPP helpful for things like this.

Hope that helps
James

Hey James,

thank you very much!

Best,
Jens

You may use the libswscale of the avlib or ffmpeg library.
In case that you need help i will be glad to help, feel free to mail me.

www.chasapis.com

Having issues converting from YUV to RGB.

started with this formula:

r = 1.0*y + 8 + 1.402*(v-128); // r
g = 1.0*y - 0.34413*(u-128) - 0.71414*(v-128); // g
b = 1.0*y + 1.772*(u-128) + 0; // b

Tried the ones listed above but they just made it worse.

Expect this:

should look like

FrameCV_2.jpg (59.02 KiB) Viewed 10699 times

Got This with orig conversion:

FrameCV_13.jpg (47.59 KiB) Viewed 10698 times

Got This with the formulas provided above:

formulas provided above

FrameCV_5.jpg (138.57 KiB) Viewed 10699 times

I'm running out of ideas at this point. I've tried numerous formulas and all of them just seem to make the picture worse. My component signal is even worse.

Ideas?

Hey Ed,

I guess you made some weird mistake. Did you check to use range 0-255? Also check if values do clip (keep output in range of 0-255). I use the formulas and they should work.

I found that apparently they don't convert 100% the way they should but your result seems to be some other problem.

Hope that helps,
Jens

Greetings Jens,

Thank you so much for your reply!

I was thinking the same thing yesterday about the 0-255 issue.

From the information I gathered ( I could be wrong) clamping 0 to 255 is for YUV values e.g. rgb --> .... all YUV values should be positive from 0 to 255

When going YUV to RGB values should be clamped -128 to 128 since rgb uses negative values. This is why the formulas subtract 128 from the Y values

I could be wrong about all this, but when I started doing the checking it did nothing for me.

Thought it might be the smoking gun but no dice..... Gotta figure this out.... but right now it doesn't make any sense

Greetings All,
I've still got nothing here. I don't understand how part of an image can be correctly converted and the other portion is garbage. Structurally the image is correct it's just the colors so what gives?

Why don't you use conversion helpers provided with DeckLink SDK (IDeckLinkVideoConversion::ConvertFrame)? They are SIMD optimized and implement the conversion in a very efficient way.

Have you tried going back a stage or two? If you generated test data in your conversion routine (such as a monochrome ramp or some steps) it may narrow the problem down to the input pixels, conversion or post processing. Also try extracting only the luminance and sending this result to all three channels. Then perhaps try inputting a luminance only ramp to check there is no colour information in the output pixels.

Regards,

Dave.

Greetings All,
Roman -- tried playing around with the conversion helpers. I'm doing something wrong because they cause a run time error. Debugging points to this line:

Code: Select all

videoFrame->CreateVideoFrame(width, height, (width*32)/8, bmdFormat8BitBGRA, bmdFrameFlagDefault, &dstFrame);


Dave -- well took a stab at this ... here's what I get just outputting luminance

FrameCV_1.jpg (518.88 KiB) Viewed 10492 times

still looks flaky to me

Hi Ed,

Yes, flaky. Your staircase should be the other way around - blue contributes least to the luminance channel. As for the bright pixels near to edges, is your source analogue? It looks like correct filtering has not been applied either in the analogue domain before ADC or digital filtering after. Can you input a luminance ramp and look at the conversion? Then the only high frequency edge would be the transition from the top of the ramp to the line end. You may need to do some digital filtering in your code before the conversion routine.

Regards,

Dave.

Greetings Dave,
Yes this is an analog component signal.
So I got to thinking about what you were saying with a luminance ramp. Changing the video is a pain for me so I started to think about ways I could get a grey scale image...then a voice said "yank the red and blue input to the card".

I did this and re-ran the YUV to RGB video conversion. I came up with this which I believe is what you are saying should be correct in terms of the staircase.

well...hmmm ... now the BMD website says "board attachment quota has been reached"
I'll have to see if I can upload pics somewhere else.

It does seem a bit off where there are areas of black.

Greetings All,
Well, it turns out that where you clamp matters a lot. <smile>

The basic rule to anyone else having this strange issue is this:

Make sure you check the RGB values you assign are between 0-255.

I made a big assumption that the YUV -> RGB formulas would always produce valid numbers given the YUV values were all correct and in range.

Mistake

Doing some calculations by hand I ended up with negative values going into RGB.

And I overlooked this detail in the past as I read somewhere that RGB values were between -127 and 127.

Wrong

All RGB values are between 0 and 255.

Thanks for all the help!