Bug 14526 - Poppler incorrectly renders CMYK colors
Summary: Poppler incorrectly renders CMYK colors
Status: RESOLVED MOVED
Alias: None
Product: poppler
Classification: Unclassified
Component: general (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: poppler-bugs
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on: 17499
Blocks:
  Show dependency treegraph
 
Reported: 2008-02-16 15:53 UTC by Troy Henderson
Modified: 2018-08-20 21:42 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments
Example of incorrect rendering (978 bytes, application/pdf)
2008-02-16 15:53 UTC, Troy Henderson
Details
Patch for repairing the CMYK to RGB conversion. (2.29 KB, patch)
2008-02-16 18:26 UTC, Troy Henderson
Details | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Troy Henderson 2008-02-16 15:53:00 UTC
Created attachment 14361 [details]
Example of incorrect rendering

It seems that poppler is incorrectly rendering CMYK colors.  Specifically, the attachment is a picture of a cyan (1,0,0,0) filled color which should convert to RGB (0,1,1) but is being converted incorrectly to (0,0.67,0.93).

The file GfxState.cc seems to be the culprit.  I changed this file by editing the function to contain (sorry but I don't know how to write patches)

void GfxDeviceCMYKColorSpace::getRGB(GfxColor *color, GfxRGB *rgb) {
	double c, m, y, k, k1, r, g, b;
	
	c = colToDbl(color->c[0]);
	m = colToDbl(color->c[1]);
	y = colToDbl(color->c[2]);
	k = colToDbl(color->c[3]);
	k1 = 1 - k;
	r = (1-c)*k1;
	g = (1-m)*k1;
	b = (1-y)*k1;
	rgb->r = clip01(dblToCol(r));
	rgb->g = clip01(dblToCol(g));
	rgb->b = clip01(dblToCol(b));
}

After changing this function to this, everything seems to work as normal.
Comment 1 Troy Henderson 2008-02-16 18:26:29 UTC
Created attachment 14362 [details] [review]
Patch for repairing the CMYK to RGB conversion.
Comment 2 Troy Henderson 2008-02-16 18:27:32 UTC
My code wasn't quite up to PDF specifications.  I have modified my code (to account for this specification) and have learned how to create patches ;).  See attachment for the patch.

Troy
Comment 3 Adrian Johnson 2008-02-16 23:58:42 UTC
I opened your sample PDF in Poppler, Ghostscript, and Adobe Reader and compared the color.

The results are:

Viewer        RGB (on a 0-255 scale)
------------------------------------
Poppler          (0, 173, 239)
Adobe Reader     (0, 174, 239)
Ghostscript      (0, 255, 255)

The Poppler results closely match Adobe Reader.

Adobe Reader implements color management which gives much better
results than a simple (1-c) conversion. I don't know the specifics of
what Adobe Reader is doing and the Poppler code for doing the CMYK to
RGB conversion has no useful comments. However it is clear that
Poppler is doing the same thing as Adobe Reader (for this one color at
least).
Comment 4 James Cloos 2008-02-17 13:58:50 UTC
If you browse to:

http://cvs.ghostscript.com/cgi-bin/viewcvs.cgi/ghostscript/trunk/gs/Resource/ColorSpace/

you can look at the default colorspace transforms used by current GhostScript.

In specific, look at http://cvs.ghostscript.com/cgi-bin/viewcvs.cgi/ghostscript/trunk/gs/Resource/ColorSpace/DefaultCMYK where you see the matrix used to emulate what Adobe Reader does.

Especially look at the comments to checkin 5401 (from 2004/October), where they mention that the intent is to show what the colours will look like when printed.


Clearly xpdf tries to emulate the look of acrobat reader, hense the colour space conversion in GfxState.cc.

Poppler probably should support both conversions, preferably with a generic colour space matrix just like GhostScript and other RIPs do.
Comment 5 Troy Henderson 2008-02-17 14:43:16 UTC
Well, the problem seems to be that neither Adobe nor Poppler is rendering this particular PDF correctly (even though their renderings are essentially the same).  It seems that Adobe isn't following its own PDF Reference at

http://www.adobe.com/devnet/pdf/pdfs/PDFReference.pdf

since its rendering (for this color) is bad.  Section 6.2.4 on page 380 of this document shows the conversion formula for which the patch that I provided implements.

So it seems that something is not consistent here.  Is Adobe's formula wrong?  It seems to be working properly for the patch I provided and the PDF I provided.  Is Adobe incorrectly implementing its own formula?  Is Adobe even using this formula?  Is Adobe incorrectly implementing a formula similar to GhostScript?  If this incorrect implementation is in fact what is happening, is Poppler making the same mistake as Adobe in its implementation (since their results seem to be virtually identical)?  Is there something wrong with my provided PDF?  It was generated from preview.eps which was generated using MetaPost, and it renders as expected in GSView and Evince (which both use GhostScript).  It was converted to PDF using GhostScript (namely `epstopdf').  Has this conversion changed the colors?

Thoughts?
Comment 6 Brad Hards 2008-02-18 11:39:27 UTC
I asked Leonard Rosenthal (from Adobe) about this:

Color - what fun ;).

As you know, Poppler/Xpdf uses an explicit algorithm (sometimes called
the "Red book" algorithm, since it comes from the Postscript Red Book)
to convert among the various DeviceXXX color spaces. However Acrobat and
Reader are fully color managed applications, which means that they
ALWAYS associate ICC profiles with DeviceXXX colors and use a CMM to
convert colors as necessary.  Reader users, however, get a "fixed set"
of profiles while Acrobat users are able to change theirs
(Preferences->Color management) - so there are times where even Acrobat
and Reader display different colors when dealing with DeviceCMYK let
alone our apps vs. Poppler/Xpdf.

There is a second potential area involved which is a setting/preference
available in Acrobat & Reader called "overprint preview" which changes
the entire drawing model from a standard "screen" model to one that
simulates "print".  Due to how this works, it's also possible to see
color shifts between the two when this preference is set.

Finally, and I believe we've talked about this one before -
transparency!  When transparency is present in a PDF AND no
"transparency page group" exists, the PDFRef says that the viewer is
free to choose what space to use.  Acrobat/Reader chooses CMYK while
every other viewer sticks with RGB - thus in such PDFs you see a color
shift between our viewers and others.

I would LOVE to see someone add color management (using lcms) to
Poppler/Xpdf!
Comment 7 Troy Henderson 2008-02-18 12:11:07 UTC
Bottom line then ... what does this discussion say about displaying
cyan as cyan, say?  Does it mean that there should be "two" types of
conversions, namely for print and screen?

Troy
Comment 8 Pino Toscano 2008-10-05 09:10:57 UTC
Should this bug depend on bug #17499 ?
Comment 9 Albert Astals Cid 2008-10-05 14:28:49 UTC
Yeah, why not
Comment 10 Minta Vacca 2015-11-19 08:34:34 UTC
Thoughtful analysis ! Speaking of which , if you is interested in merging of two PDF files , I discovered a service here <a href="http://www.altomerge.com/" >AltoMerge.com</a> and also here PDFfiller.com
Comment 11 GitLab Migration User 2018-08-20 21:42:40 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/poppler/poppler/issues/41.


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.