topic Jpeg sample cannot read YCbCr Lossless file in Intel® Integrated Performance Primitives

Jpeg sample cannot read YCbCr Lossless file

Thomas_Jensen1 — Thu, 06 May 2010 21:36:32 GMT

I found an image file that UIC sample cannot read properly.
It is an YCbCy Lossless 8u_c3 Jpeg file. It decodes wrongly to a "swapped rgb channel" image.
The file is actually a grayscale x-ray image, saved as RGB, but using YCbCr color space, and compressed Losslessly.

When loaded by a properly operating program, it looks like a grayscale x-ray image.
When loaded by UIC (IPP\\6.1.5.054\\ipp-samples\\image-codecs\\uic\\bin\\win32\\picnic.exe), it looks green with pinks spots.

It seems that, although the decoder sets output color space to RGB, the decoder still puts YCbCr data in the output buffer.

I attached the file:

Jpeg sample cannot read YCbCr Lossless file

Vladimir_Dudnik — Fri, 07 May 2010 05:57:27 GMT

Hi Thomas,

I believe this question was discussed on the forum many times. There is nothing in standard JFIF/JPEG file what says you about color space used at compression time that cause JPEG decoder itself and application which calls it have to made a certain assumptions on this. Usually JFIF file with lossy compression for 8-bits 3 color channels considered to be YCbCr image and decoder will apply YCbCr-to-RGB color conversion on it. In case of lossless compression, decoder will assume RGB image.If you know appriory color space used (like in your case if you know that RGB-toYCbCr conversion was applied at compression stage) you just need tospecify JPEG color space to decoder, so it will know thatinverse conversion step is required to correctly reconstruct the original data.

Regards,
Vladimir

Jpeg sample cannot read YCbCr Lossless file

Thomas_Jensen1 — Fri, 07 May 2010 10:05:12 GMT

The code in jpegdec.cpp contains:

if(JO_READ_HEADER == op)
{
// detect JPEG color space
if(m_jfif_app0_detected)
{
switch(m_jpeg_ncomp)
{
case 1: m_jpeg_color = JC_GRAY; break;
case 3: m_jpeg_color = JC_YCBCR; break;
default: m_jpeg_color = JC_UNKNOWN; break;
}
}

, and since the file does have an APP0 tag, and since ncomp = 3, then this UIC sample code wrongly assumes that this losslessly compressed Jpeg file has JC_YCBCR color space. It should have assumed JC_RGB color space since compression is lossless.

I added this modification:

case 3: m_jpeg_color = m_jpeg_mode == JPEG_LOSSLESS ? JC_RGB : JC_YCBCR; break;

It seems to fix the problem, but I can't be sure.
Maybe it should not be JC_RGB for lossless, but JC_UNKNOWN?

I also took a look at keeping the lossless at JC_UNKNOWN, and then fixing the code in ColorConvert():
// RGB to BGR
if(m_jpeg_color == JC_RGB && m_dst.color == JC_BGR)

changed to:

// RGB to BGR
if((m_jpeg_color == JC_RGB || m_jpeg_mode == JPEG_LOSSLESS && m_jpeg_color == JC_UNKNOWN) && m_dst.color == JC_BGR)

That also take care of the problem.

I still think UIC sample has a bug, because for lossless comression, it assume YCbCr, whereas it should actually assume nothing, or RGB.

Jpeg sample cannot read YCbCr Lossless file

Vladimir_Dudnik — Fri, 07 May 2010 21:03:02 GMT

I agree that for lossless compressionmore appropriateassumtion should be RGB for 3-channel image. We will check and correct if that is not true. Just note, that such assumption is not part of JPEG standard.

Vladimir

Jpeg sample cannot read YCbCr Lossless file

Thomas_Jensen1 — Sun, 09 May 2010 00:34:26 GMT

Today, IPP sample code assumes a 3-channel image is YCbCr, that is certainly a wrong assumption.