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

[gcode-importer]

Originally reported on Google Code with ID 324

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. 

Reported by detonin on 2014-04-01 19:40:56

[gcode-importer]

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

Reported by szukw000 on 2014-04-03 16:07:55

[gcode-importer]

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

Reported by szukw000 on 2014-04-03 20:42:48

---

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