[Poppler-bugs] [Bug 34053] Poppler ignores rendering intents and always uses INTENT_RELATIVE_COLORIMETRIC

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=34053

--- Comment #7 from Hal Engel <hvengel at astound.net> 2011-02-09 13:03:13 PST ---
Sorry, I am not sure exactly how the PDF dictionary is structured or used.  But
the section of the spec. that talks about rendering intents is 8.6.5.8 in the
PDF 1.7 specification where the relevent part says:

"Rendering intents shall be specified with the ri operator (see 8.4.4,
"Graphics State Operators"), the RI entry in a graphics state parameter
dictionary (see 8.4.5, "Graphics State Parameter Dictionaries"), or with the
Intent entry in image dictionaries (see 8.9.5, "Image Dictionaries"). The value
shall be a name identifying the rendering intent. Table 70 lists the standard
rendering intents that shall be recognized. Figure L.5 in Annex L illustrates
their effects. These intents have been chosen to correspond to those defined by
the International Color Consortium (ICC), an industry organization that has
developed standards for device-independent colour.  If a conforming reader does
not recognize the specified name, it shall use the RelativeColorimetric intent
by default."

What is needed is to figure out the correct rendering intent to use when
creating transforms based on the dictionary contents.

Setting the intent for the transforms happens in GfxColorSpace
*GfxICCBasedColorSpace::copy() where the code looks like this (the below starts
at line 1512 in version 0.16.2):


    cmsHPROFILE dhp = displayProfile;
    if (dhp == NULL) dhp = RGBProfile;
    unsigned int cst = getCMSColorSpaceType(cmsGetColorSpace(hp));
    unsigned int dNChannels = getCMSNChannels(cmsGetColorSpace(dhp));
    unsigned int dcst = getCMSColorSpaceType(cmsGetColorSpace(dhp));
    cmsHTRANSFORM transform;
    if ((transform = cmsCreateTransform(hp,
       COLORSPACE_SH(cst) |CHANNELS_SH(nCompsA) | BYTES_SH(1),
       dhp,
       COLORSPACE_SH(dcst) |
         CHANNELS_SH(dNChannels) | BYTES_SH(1),
      INTENT_RELATIVE_COLORIMETRIC,0)) == 0) { ...

Where INTENT_RELATIVE_COLORIMETRIC is hard coded.  This instead needs to be
based on the rendering intent that should be part of the of the dictionary data
for ICCBased objects.  Either this is the document level default rendering
intent or it is the object specific rendering intent.

Also the intents listed in Table 70 are the basic ICC intents.  LCMS and some
other CMS's also support relative colormetric + black point compensation.  It
would be nice if this was also supported by poppler. 

Also the above code makes the assumption that all objects in the PDF are 8
bits/channel.  This may actually be true for most PDFs but what happens if it
is passed a PDF with a 16 bit/channel image or perhaps a PDF with a float
encoded TIFF that is embedded?  I see in section 8.9.3 of the spec that the
dictionary should have the number of bits per colour component so this should
not be difficult to fix.  But perhaps this should be in a separate bug report.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.