10bit 422 to unsigned short RGB (3x16bit) ?

59 views
Skip to first unread message

iptrkpfn

unread,
Jul 19, 2012, 4:32:47 PM7/19/12
to pixf...@googlegroups.com
Hi Frank,

I wondered if/why there is no conversion in pixfc-sse for getting from 422 to a 48bit (or 64bit) RGB(A) pixel format (to keep the full bit depth of the source 10bit YCbCr buffers).

I browsed through the code of pixfc-sse, unfortunately without fully understanding it. But it seems you do an RGB packing step at the end of each YUV2RGB conversion. Could a packing be added that packs to 16bit RGB instead of 8it RGB? Or is the bit depth already lost at for that step?

Thanks for your help!

Best,
Patrick

Pix FC

unread,
Jul 19, 2012, 7:22:49 PM7/19/12
to pixf...@googlegroups.com
Hi Patrick,
You are correct, at the output of yuv2rgb inlines each component is indeed 16-bit wide, but because the currently supported pixel formats are all 8-bit wide, all component values in the conversion pipeline will take up to 8-bit (in a 16-bit wide container). I started working on adding support for 10-bit formats and will be doing this in stages. I just finished adding conversions to/from 10bit YUV format (aka v210), and I am currently fixing a few conversion bugs here and there. If you wish to test it, checkout the SVN branch at http://pixfc-sse.googlecode.com/svn/branches/add-10bit . The next step is to add support for 10-bit RGB.

And yes, the macro "situation" makes it quite hard to follow what's going on inside pixfc. I m planning to write up a page detailing how to dig into the code, but essentially, you start with a conversion function in conversion_routines_from_xxx.c which is defined using a single macro, then go to the definition of that macro and find out which conversion recipe is used (called xxxx_TO_yyyy_RECIPE). The conversion recipes can be found in  yuv_conversion_recipes.h and rgb_conversion_recipes.h. They contain the core of the conversion code and calls the correct inline functions to do the job, usually broken up into the following blocks: unpacking -> up/downsampling -> conversion -> packing. Between each of these blocks, components are all 16-bit wide, but currently only use 8-bit as explained above.
Hope this helps.

Cheers,
Frank

iptrkpfn

unread,
Jul 20, 2012, 12:14:39 PM7/20/12
to pixf...@googlegroups.com
Hi Frank,

thanks for clarifying! I don't know if a comprehensive documentation for the architecture of pixfc-sse is necessary, your comments on how to follow the macros down to the real implementation already helped, thanks! I will see if I can test the 8bit version of the v210 to RGB conversions next week.

Best,
Patrick
Reply all
Reply to author
Forward
0 new messages