Jpeg sample cannot read YCbCr Lossless file

[Thomas_Jensen1]

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:

[Vladimir_Dudnik]

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

[Thomas_Jensen1]

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.

[Vladimir_Dudnik]

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

[Thomas_Jensen1]

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