YUV420SP to RGB on DM6467T

Helmut,

Please see the answers embedded below

I find in imglib2 (http://focus.ti.com/lit/ug/spruf30a/spruf30a.pdf) the function IMG_ycbcr422p_rgb565 that seems promising.  It can process 4:2:0 one line at a time.  But is this semiplanar or planar?  I'm not sure.

-> This function converts YUV422 Planar data to packed RGB data.

[EDIT] found chroma down/up conversion (422 <-> 420) in capture.c/display.c derived from encodedecode demo, using Ccv_execute() and related API for VDCE.  This assures me I'll be able to omit this and start with 422SP instead of 420SP.  Still need to get to RGB...

[NEW EDIT} successfully stripped down/up conversion by VDCE and increased buffer size since 422 takes more than 420.  So now I have YUV422SP going through codec and I need to convert that to RGB.

-> You can implement the color space conversion from in software on the DSP using the tool called "C6Accel". It is an xdais algorithm similar to the codecs and needs to be integrated in your codec server. Please refer the following wikis for more information

http://processors.wiki.ti.com/index.php/C6Accel

http://processors.wiki.ti.com/index.php/Using_C6Accel_on_DM6467_with_DVSDK_3.x

http://processors.wiki.ti.com/index.php/C6Accel_Image_Processing_API_Reference_guide

WIth the current functions available in C6Accel you will need to convert YUV422SP -> YUV420PL-> RGB565

Also you might find this post useful as a bug on the YUV422SP to YUV420PL was recently fixed.

http://e2e.ti.com/support/embedded/f/355/p/90049/313276.aspx#313276

Regards,

Rahul

Thanks, Rahul.

I found C6Accel late this afternoon.  When I read the wiki, it sounded like it had to be called from the ARM.  You're suggesting it's called from the DSP.  Or can it be called from either?

My app on the ARM is doing buffer handling.  I guess I could have it call a C6Accel function before and after calling my own _process() function.  In fact, it was already making use of VDCE.  And there might be some pipelining.  

I'll look into this further.

Also, the "565" concerns me.  I think my wikipedia reference for converting YUV to RGB yield more than just 5 or 6 bits.  Resolution/accuracy is very important to me.  Am I confused somewhere here?

In addition, looking at the C6Accel_Reference_guide.pdf page 3 figure, it appears that C6Accel might just be a wrapper for DSPLIB, IMGLIB, and MATHLIB.  If this is the case, I could possibly use those libs directly from my codec without the C6Accel complication at all.  (Yes, since I'm already writing a codec, C6Accel is a complication.)  So, I have DSPLIB and IMGLIB2, but I can't find a MATHLIB.  In addition, Image_Processing_kernels_in_C6Accel.pdf documents functions (such as C6Accel_IMG_ycbcr422sp_to_ycbcr420pl) for which I don't find an equivalent in DSPLIB or IMGLIB2.  Is C6Accel "originating" some of these functions, or are they in MATHLIB, or do I just need a newer version of DSPLIB or IMGLIB2?

Thanks again,

Helmut

Also, to repeat, is RGB565 only 16 total bits of color?  This must be significant information loss.  Am I mistaken?

I do understand that YUV422 is U,Y1,V,Y2 for 2 pixels.  That averages 16 bits per pixel.  But for each pixel, RGB comes from U,Y#,V, which is 24 bits.  Let me think.  If I have a vector in YUV space where Y is the brightness and UV is the color, then...  OK, Y brightness varies from 16 to 255.  Next, in RGB space I take a vector whose magnitude is brightness.  That's 3.46*256 = maybe 885 max magnitude.  This is still on the same order as the Y's 255, so magnitude matches.  Now take RGB space ANGLE as the color.  For mid magnitudes, the angle can sweep out a triangle that's on the diagonal of the 3D RGB cube. That triangle has sides 1.44*256 = 369.  Area 47232 I believe, corresponds to 217 squared.  logbase2(217) is 7.76.  So that's 7.76 bits by 7.76 bits, or 15.52 bits.  I'm thinking the resolution really is there.  (That was very quick and rough calculating)

I found C6Accel late this afternoon.  When I read the wiki, it sounded like it had to be called from the ARM.  You're suggesting it's called from the DSP.  Or can it be called from either?

-> Yes, It is a tool for an ARM application to invoke functionality on the DSP.

My app on the ARM is doing buffer handling.  I guess I could have it call a C6Accel function before and after calling my own _process() function.  In fact, it was already making use of VDCE.  And there might be some pipelining.  

-> You can use C6Accel before or after the process call to your codec  as C6Accel is suited for such kind of pre or post processing of data obtained or given to the codec.

I'll look into this further.

Also, the "565" concerns me.  I think my wikipedia reference for converting YUV to RGB yield more than just 5 or 6 bits.  Resolution/accuracy is very important to me.  Am I confused somewhere here?

-> RGB 565 is a popular 16bit format which most display drivers handle and I don`t believe there is loss of resolution here.

In addition, looking at the C6Accel_Reference_guide.pdf page 3 figure, it appears that C6Accel might just be a wrapper for DSPLIB, IMGLIB, and MATHLIB.  If this is the case, I could possibly use those libs directly from my codec without the C6Accel complication at all.  (Yes, since I'm already writing a codec, C6Accel is a complication.)  So, I have DSPLIB and IMGLIB2, but I can't find a MATHLIB.  In addition, Image_Processing_kernels_in_C6Accel.pdf documents functions (such as C6Accel_IMG_ycbcr422sp_to_ycbcr420pl) for which I don't find an equivalent in DSPLIB or IMGLIB2.  Is C6Accel "originating" some of these functions, or are they in MATHLIB, or do I just need a newer version of DSPLIB or IMGLIB2?

-> Yes, most function in C6Accel originate from the DSPLIB, IMGLIB and the MATHLIB(IQMATH and FASTRTS libraries) but several additional DSP optimized functions have been added to it. IMG_ycbcr422sp_to_ycbcr420pl is one of these functions. If you are interested in the source code of any of these functions write to us at http://processors.wiki.ti.com/index.php/C6Accel#Developer_Mailing_List 

Let us know if we can be of any help

Regards,

Rahul

Here's a more rigorous proof that RGB565 looses a lot of information.  Therefore, I'm still interested in MATHLIB, any RGB888 functions, and example source to MATHLIB, DSPLIB, C6Accel, or VLIB (fat chance).

Consider the information question by averaging together two adjacent pixels.  Such averaging generally increases the bits of information in the result.  Specifically...

Y varies from 16 to 235.  This corresponds to 7.77 bits.

U and V each should vary from 0 to 255, corresponding to 8 bits.

Averaging two pixels together in YUV space will yield the same U and Y, but the average of Y1 and Y2.  Averaging these 7.77 bit values together yields an 8.77 bit value.  So the total bits of information in the result is 24.77 bits.

Now do the same with RGB565.  Averaging two 5-bit red (blue) values produces a 6-bit red (blue) value.  Averaging two 6-bit green values produces a 7-bit green value.  Adding these together yields 19 bits.

So 5.77 bits of information is lost when converting two pixels of YUV422 to two pixels of RGB565, and counting "information" based on averaging each pair of pixels together.  Whether more or less information is individually lost, I'm uncertain.  But I am certain there's a lot of loss.

Perhaps the true answer is to just consider Y1, U, V as 24 bits.  The information loss going from the original image to the YUV422 format is not recoverable, and that information loss makes two adjacent pixels appear the same color (chroma) but with different brightnesses (luminance).  But still, what's left has 24 bits of information.  The RGB565 result will still have the loss in color differentiation between the two adjacent pixels.  But individually, they still only have 16 bits of color.  So it's 24 vs 16, or 8 bits of information lost.  EDIT: 23.77 bits vs 16 bits.  7.77 bits lost.

Yep, I need RGB888 without passing through RGB565.  So it appears none of the color space conversion functions found so far will help (other than perhaps a semi-planar to planar step).  Does anyone know of an RGB888 conversion?  Otherwise, I'll need to code it myself using IMGLIB2 and... can we find MATHLIB?  It's simply a case of taking the formulas for a single pixel and coding them as a vector across the whole slice or frame.

Rahul,

I didn't see your response before I posted again...

Thanks for the clarifications.

I'll look for IQMATH and FASTRTS libraries tomorrow.

Thanks for the source code advice.  I'll follow up on that as well.  If my boss allows, I might be able to feed back an RGB888 conversion derived from the source I get.  The best would be a native-DM6467T-supporting single YUV422SP-to-RGB888PL conversion function.

-Helmut

FYI, I found was I was originally looking for:  "Intrinsic" functions per section 7.5.5 of http://focus.ti.com/lit/ug/spru187r/spru187r.pdf .  However, even though this is what I had found a year ago and was looking for now, it's NOT the best tool to do what I need.  Instead, I find IMGLIB source I can modify.

Hi,

I am using DM368EVM with DVSDK4. I want to convert Mpeg4dec output (YUV420 semi planer and YUV422 interleaved) to RGB, to display over LCD. Is it possible using DM368EVM. 

Hello, 

Has anybody done YUV422 to RGB565? I need an example how to do it.

Kind regards,

Yes, but it's company proprietary so unfortunately I can't share it.

Use the intrinsic functions I mentioned before.  Or, I also found that my video output chip could do it.