Single component JP2 files with restricted ICC profile always lead to 3-components output.

[GoogleCodeExporter]

file8.jp2 in the conformance test suite is correctly decoded but is mapped into 
a 3-components output image, due to its restricted ICC profile. 

Indeed, in color.c, when a ICC profile is present and out_space is 
cmsSigGrayData, it ends up with a sRGB colorspace although it should be a 
grayscale colorspace.

Current implementation does make the conformance test pass but this is due to a 
misunderstanding (or a defect ... to be clarified in JPEG committee) of the 
conformance files. Actually, all reference TIF conformance files are 8-bits 
sRGB: these conformance files should be adapted to the actual output device 
before being compared to the decoder output.

In this case, only first component of jp2_8.tif has to be taken into account 
when comparing file8.jp2.tif (test output) and jp2_8.tif. 

Original issue reported on code.google.com by anto...@gmail.com on 1 Apr 2014 at 7:40

[GoogleCodeExporter]

Antonin,

>Indeed, in color.c, when a ICC profile is present and out_space 
>is cmsSigGrayData, it ends up with a sRGB colorspace although 
>it should be a grayscale colorspace.

That does not work with LCMS:

in_type = TYPE_GRAY_8;
out_type = TYPE_GRAY_8;
cmsCreateTransform() returns NULL

But:

in_type = TYPE_GRAY_8;
out_type = TYPE_RGB_8;

does work.

I work on a patch of this.

winfried

Original comment by szukw...@arcor.de on 3 Apr 2014 at 4:07

[GoogleCodeExporter]

This patch is a little bit lengthy. It additionally contains
the answer to Issue 326: the CIELab image.

cmsSigGrayData is now handled for a precision <= 8 and a
precision > 8.

The resp. LCMS types are

 TYPE_GRAY_8 to TYPE_RGB_8
 and
 TYPE_GRAY_16 to TYPE_RGB_16

Unhandled is the ICC Color space cmsSigYCbCrData. Shall it
be refused?

winfried

Original comment by szukw...@arcor.de on 3 Apr 2014 at 8:42

Attachments:

• openjpeg-2.x-trunk-r2833-2.dif.gz