Bug 60383 - CMYK JPX images not supported
Summary: CMYK JPX images not supported
Status: RESOLVED FIXED
Alias: None
Product: poppler
Classification: Unclassified
Component: general (show other bugs)
Version: unspecified
Hardware: All All
: medium minor
Assignee: poppler-bugs
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-02-06 21:45 UTC by Harry Roberts
Modified: 2016-03-17 15:28 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments
Example PDF page which has this problem (506.38 KB, application/pdf)
2013-02-06 21:45 UTC, Harry Roberts
Details
Affected image, extracted with pdftoimages (21.14 KB, image/jpeg)
2013-02-06 21:45 UTC, Harry Roberts
Details
Page rendered with Photoshop - shows correct rendering (202.94 KB, image/jpeg)
2013-02-06 21:46 UTC, Harry Roberts
Details
Poppler 0.22 with libopenjpeg support (376.45 KB, image/jpeg)
2013-02-06 23:12 UTC, Harry Roberts
Details
Example of image which is inverted with libopenjpeg enabled (3.29 KB, image/jpeg)
2013-02-06 23:26 UTC, Harry Roberts
Details
JPX image incorrectly identified as 'grey' (4.39 KB, image/jpeg)
2013-02-07 00:58 UTC, Harry Roberts
Details
Greyscale JPEG 2000 image (lower half of O) (4.67 KB, image/jp2)
2013-02-07 06:12 UTC, Harry Roberts
Details

Description Harry Roberts 2013-02-06 21:45:21 UTC
Created attachment 74307 [details]
Example PDF page which has this problem

In the example PDF the shadow behind the large 'Oxygen' title is a CMYK JPX stream.

It seems like the JPX stream is decoded correctly, but internally Poppler thinks the decoded image is RGB, or some similar situation. Because of this the stride is screwed and the image is repeated several times with the remaining space being garbled data.

This problem occurs with:

 * Evince + Poppler 0.20 + LCMS 2.2 (without openjpeg)
 * pdftoppm + Poppler 0.22 + LCMS 1.19 (without openjpeg)
 * Google Chrome 24.0 (stable)

The PDF renders correctly with:

 * Adobe Acrobat
 * Adobe Photoshop
 * GhostScript

More files will be attached that show the problem.

A workaround would be to build Poppler with OpenJPEG support?
Comment 1 Harry Roberts 2013-02-06 21:45:59 UTC
Created attachment 74308 [details]
Affected image, extracted with pdftoimages
Comment 2 Harry Roberts 2013-02-06 21:46:44 UTC
Created attachment 74309 [details]
Page rendered with Photoshop - shows correct rendering
Comment 3 Harry Roberts 2013-02-06 23:12:26 UTC
Created attachment 74310 [details]
Poppler 0.22 with libopenjpeg support

When Poppler is built with libOpenJPEG support it still doesn't render correctly.

libopenjpeg was built with: --disable-dependency-tracking --disable-shared --disable-doc --disable-png --disable-tiff --disable-lcms2

Some segments of the shadow look correct, but other bits don't. This is better than nothing, but there is still an underlying problem I am investigating.
Comment 4 Harry Roberts 2013-02-06 23:26:08 UTC
Created attachment 74311 [details]
Example of image which is inverted with libopenjpeg enabled

The lower half of the 'O' which looks like an inverted alpha mask is a greyscale JPX image, extracting with `pdfimages` attached.

page   num  type   width height color comp bpc  enc interp  object ID
---------------------------------------------------------------------
   1     9 image     132    59  gray    1   8  jpx    no        66  0
Comment 5 Harry Roberts 2013-02-07 00:58:45 UTC
Created attachment 74312 [details]
JPX image incorrectly identified as 'grey'

Extracted the lower half of the 'O' from Oxygen with Acrobat - seems like it's being incorrectly identified as a greyscale image when it is full color image.
Comment 6 Harry Roberts 2013-02-07 06:12:41 UTC
Created attachment 74320 [details]
Greyscale JPEG 2000 image (lower half of O)

Attached is one of the problem JPEG2000 images extracted from the PDF.

j2k_to_image from the openjpeg package displays it as black & white rather than in CMYK. This is an openjpeg problem.

From: https://groups.google.com/forum/?fromgroups=#!topic/openjpeg/D3D1gv5FYx0
> PDF uses a superset of JP2 format known as JPX. The differences are 
> small but some of the important features are missing from OpenJpeg. 
> For instance, OpenJPEG doesn't recognize CMYK data. 
> Is there any plans to extend the library to support JPX? 

*sigh*

So the options are:

 1) Implement CMYK JPX support in openjpeg
 2) Implement CMYK JPX support in Poppler's own JPX stuff
 3) Give up and cry, it is only one PDF (I hope)
Comment 7 Albert Astals Cid 2013-03-03 18:29:34 UTC
We do not need CMYK support in openjpeg since we only use openjpeg for decoding.
Comment 8 Albert Astals Cid 2013-03-03 18:48:52 UTC
ok, forget what i said, for some kind of images we do ask openjpeg how many components the image has, and here it is return 1 component and thus bad stuff happens
Comment 9 Thomas Freitag 2016-03-17 15:28:23 UTC
Fixed in actual version (with openjpeg enabled)


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.