[Openicc] The OutputIntent and Color Managed Printing

Chris Murphy chris at colorremedies.com
Mon May 20 13:45:59 PDT 2013


On May 20, 2013, at 2:02 PM, Gerhard Fuernkranz <nospam456 at gmx.de> wrote:

> In particular section 3.3 seems to defeat my intuitive re-targeting expectations, though :-(
> Actually I would expect that re-targeting to another printer does take the gamut of the other printer into account.

PDF/X-1a it would. PDF/X-3 it would not, unless the content is already /DeviceCMYK (i.e. OutputIntent space)

/ICCBased objects in PDF/X-3 are expected to print differently between OutputIntent and a different actual output device. This is not proofing, and is in that sense a meaningful distinction between retargeting and proofing.

Section 3.3, Paragraph 1 and 2 of the cited document is highly optimistic if it's considering the embedded OutputIntent profile's tonality, gamut compression, black generation and UCR even remotely discoverable by software other than that which created that profile. So it's a totally closed loop expectation.

The consequences of prematurely setting the OutputIntent is similar to that of premature binding. In the latter case, the rendering is baked in and there isn't a practical way to unwind it without a totally v4 + PRMG workflow. In the former case, while the original unconverted data is available, there's possibly a rendering expectation already in mind, possibly even physical proofs exist and have been signed off on.

So it's plausible retargeting means turning the actual press into a proofing device for the Output Intent (i.e two transforms per device independent object); just as it's plausible the wrong OutputIntent is replaced with the correct one, where a single transform is indicated per device independent object, along with new proofs being ordered.



> Let's assume I've got a PDF intended for offset printing, and I'm a dumb user, not knowing anything about output intents, proofing, etc., and I simply want to print (not proof) this document on my laser printer on normal office paper (-> which has a rather limited gamut and cannot reproduce very dark black).
> 
> What was my expectation then? I certainly
> would not want to get clipped shadows or too strongly clipped saturated colors (due to the offset print gamut being larger than my printer's gamut)
> 
> would not want to get paper color emulation (which at least absolute colorimetric proofing would do)
> 
> but I rather would like to get a pleasing reproduction of the document on _my printer_, which implies that also the gamut must be remapped according to the needs of my printer
> An (absolute or relative) colorimetric proof would certainly not yield the desired results in this case.


Is a good example of why the user's expectations need to be established in the print dialog. Do they want it to look good on that printer, or do they want it to simulate the intended printer?

And of course in this example the offering to simulate the intended printer is possibly very misleading if the local printer can't actually simulate the gamut and/or dynamic range of the OutputIntent. In that case it's really "Closest simulation possible".



> 
> How could one, for instance, achieve the desired output?
> Use perceptual (not colorimetric) rendering intent for the proofing transformation (but can we call it "proofing" or "emulation" any more then?)

Maybe for v2. But if the OutputIntent were a v4 profile with PRGM, the use of perceptual in effect does gamut expansion back to the PRGM state, then the new output profile does gamut compression from the PRGM state (re-rendering).

> 
> or use the output intent color space only as DefaultCMYK (in case that there are any DeviceCMYK colors used in the document), and convert CIE-based colors in the document still directly to my printer's profile.

The user's expectations are varied. To do the right thing, we'd need to know what they expect.


Chris Murphy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/openicc/attachments/20130520/e19f97db/attachment.html>


More information about the openicc mailing list