ippiYCbCrToBGR_709CSC Crashes

[BatterseaSteve]

Hi

I am looking at, and trying to use the ippiYCbCrToBGR_709CSC function to convert an image.

The parameter lists dictate a planar YCbCr image but the srcStep is specified as an int. The doc for srcStep

actually says

"An array of distances in bytes between starts of consecutive lines in the source image planes"

But its type is int. - I would have expected an array of ints.

I am assuming that the YCbCr is 4:2:2

Either way, I have tried width and width/2 but it still seems to convert to garbage.

I have checked out my src bytes and they look OK

Am I missing something here?

Steve

[BatterseaSteve]

This is the outline of the code I am using

IppiSize rgbRoi = {width,height};

Ipp8u *rgbImage = ippsMalloc_8u(width*height*sizeof(Ipp8u)*3);

Ipp8u *Y = ippsMalloc_8u(width*height*sizeof(Ipp8u));

Ipp8u *U = ippsMalloc_8u(width*height*sizeof(Ipp8u)/2);

Ipp8u *V = ippsMalloc_8u(width*height*sizeof(Ipp8u)/2);

Ipp8u *pDst[] = {Y,U,V};

int dstStep[] = {width,width/2,width/2};

// convert packed to planer (buffer contains CbYCr packed)

ippiCbYCr422ToYCbCr422_8u_C2P3R(buffer, width*2,pDst,dstStep, rgbRoi);

// conver planer to BGR

ippiYCbCrToBGR_709CSC_8u_P3C3R((const Ipp8u** )pDst, width, rgbImage, width*3, rgbRoi);

This actually crashes. If I set width in the 709 func to be width/2, it does not crash but it yields garbage

If I useippiCbYCr422ToBGR_709HDTV_8u_C2C3R(buffer,width*2,rgbImage,width*3,rgbRoi);

My image is correct (but in the wrong colour space) so I know the incomming pixels are OK.

ANy help gratefully received

Steve

[SergeyKostrov]

Hi Steve,

Quoting BatterseaSteve

...
I am assuming that the YCbCr is 4:2:2
...

Here is a quote from ippi.h header file to confirm it:

...
// The YCbCr color space was developed as part of Recommendation ITU-R BT.601
// (formely CCI 601). Y is defined to have a nominal range of 16 to 235;
// Cb and Cr are defined to have a range of 16 to 240, with 128 equal to zero.
// The function ippiRGBToYCbCr422_8u_P3C2R uses 4:2:2 sampling format. For every
// two horisontal Y samples, there is one Cb and Cr sample.
// Each pixel in the input RGB image is of 24 bit depth. Each pixel in the
// output YCbCr image is of 16 bit depth. Sequence of bytes in the output
// image is
// Y0Cb0Y1Cr,Y2Cb1Y3Cr1,...
// And for CbYCr image we have
// Cb0Y0CrY1,Cb1Y2Cr1Y3,...
// If the gamma-corrected RGB(R'G'B') image has a range 0 .. 255, as is commonly
// found in computer system (and in our library), the following equations may be
// used:
//
// Y = 0.257*R' + 0.504*G' + 0.098*B' + 16
// Cb = -0.148*R' - 0.291*G' + 0.439*B' + 128
// Cr = 0.439*R' - 0.368*G' - 0.071*B' + 128
//
// R' = 1.164*(Y - 16) + 1.596*(Cr - 128 )
// G' = 1.164*(Y - 16) - 0.813*(Cr - 128 )- 0.392*( Cb - 128 )
// B' = 1.164*(Y - 16) + 2.017*(Cb - 128 )
//
// Note that for the YCbCr-to-RGB equations, the RGB values must be saturated
// at the 0 and 255 levels due to occasional excursions outside the nominal
// YCbCr ranges.
...

Best regards,
Sergey

[BatterseaSteve]

Thanks for confirming...

So why does my example crash?

Looking at some of the examples, I can see this method signature used in lots of places and it seems that the

srcStep is the width of the Y component. Which is 1920 in my case. But if I use this it SEGV's.

In fact I have to pass in 960 (width/2) to stop it crashing.

But when I do this the o/p bgr image is bad (it looks like the width is out by 2)

I have checked the individual Y,U,V buffers and these are correct.

Steve

[BatterseaSteve]

Actually - is it 4:2:2?

Looking at the docs for Image Downsampling it says:

"4:4:4 YUV (YCbCr)- conventional format, no downsampling, Y, U(Cb), V(Cr) components are sampled at every pixel. If each component takes 8 bits, than every pixel requires 24 bits. This format is often denoted as YUV (YCbCr) with the4:4:4descriptor omitted."

[BatterseaSteve]

OK Guys - Ha Ha, very funny

Well that was a great use of 8 hours

Yes it does take a YCbCr444 image.

Why?

709 is specifically relates to broadcast signals

You could at least provide a 422 version - you do for HDTV

Or at the very least you could mention it in the doc.