<div class="gmail_quote">On Tue, Feb 28, 2012 at 10:02 AM, Kai-Uwe Behrmann <<a href="mailto:ku.b@gmx.de">ku.b@gmx.de</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Am 28.02.12, 09:25 -0800 schrieb Michael Vrhel:<div class="im"> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> On Tue, Feb 28, 2012 at 9:08 AM, Chris Murphy <<a href="mailto:lists@colorremedies.com" target="_blank">lists@colorremedies.com</a>>wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> On Feb 27, 2012, at 10:52 PM, Michael Vrhel wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> It is not true that Ghostscript will assume DeviceRGB is sRGB. </blockquote> Ghostscript can be specified to use specific ICC profiles for DeviceGray, DeviceRGB and DeviceCMYK. In fact, Ghostscript can have different source ICC profiles specified for different graphic types (e.g. text, graphics and images in DeviceRGB and DeviceCMYK color spaces). These can even override ICC profiles that are internally specified within the document. Object dependent ICC profiles can also be specified for the output device ICC profile and DeviceN source color spaces can be specified with external ICC profiles. For what it's worth, the idea of overriding embedded profiles in a document is a big problem. If the wrong source profile is embedded, the PDF needs to print like crap, and the offending user or application that produced the PDF needs to fix their error. </blockquote> The fact is that the world is a big place and there are software RIP vendors that use Ghostscript in their products and they need to have this capability. It is an option that one has available and requires a special command line option to invoke. In its vanilla calling form, Ghostscript makes use of all the embedded ICC profiles in PDF. </blockquote> </div> Honestly I share Chris' objection. I would feel much better, if you design the options in a way, that overriding a embedded profile will not happen even if a external profile is specified :-) So I think a explicite option to ignore the embedded profile, beside a external subordinate specified profile would be my wish. # the first case works compliant to PDF/X standard gs --output-profile-if-no-embedded-is-found=XXX # the second case breaks willingly the PDF/X standard and is # not prominently documented gs --output-profile-if-no-embedded-is-found=XXX --ignore-embedded Hope that satisfies both concers.<div class="im"> </div></blockquote><div> I guess we are talking about two different things here. There are two "override" conditions. Case 1: Suppose I have a source color space in a PDF file that is ICC based. It is possible in Ghostscript to actually override that source color ICC profile and replace it with a different ICC profile. To do this, requires the use of a command line option -dOverrideICC. This is the type of command line option that one really would never use if they had a properly defined PDF file. Apparently the customers for some RIP vendors receive all sorts of garbage PDFs and so they need to have the capability to override what the file says the colors are. I agree that in a perfect world this would not be needed, but unfortunately I don't write all the PDF creation software. User beware when they use this option and I doubt this command line option would be used by anyone but particular RIP vendors. Case 2: Now we are talking about Output Intent. A PDF file can have multiple output intents and the ICC profile may or may not be included in the output intent dictionaries. Because of this ambiguity, Ghostscript has been ignoring the OutputIntent. A work around for this has been to use Ghostscript to parse and dump the ICC profiles contained in the OutputIntent dictionaries using a tool called extractICCprofiles.ps in Ghostscript's toolbin directory and then to specify on the command line the particular output intent profile that you wished to used for the device and for the default source color space. For example, if there was a CMYK output intent dictionary in the file and it was the one that I wished to use, then I could first extract it using the tool. Then I would want to specify -sOutputICCProfile=my_device_profile.icc -sDefaultCMYKProfile=cmyk_profile.icc -sProofProfile=cmyk_profile.icc where obviously cmyk_profile.icc is the profile that I extracted from the dictionary and assuming that we are actually printing to a device that has a profile called my_device_profile.icc . Now, I am in the process of implementing automated use of the OutputIntent in Ghostscript. Since people are used to having Ghostscript provide a certain result, this new use of the OutputIntent by Ghostscript will be initially invoked through the use of a command line option -dUsePDFX3Profile=# where # specifies which OutputIntent to use. Now, if one does NOT specify a particular output ICC profile for their device, the file will be rendered to the output intent color space (assuming the device process color space matches the OutputIntent color space i.e. CMYK vs RGB). If someone DOES specify an ICC profile for their device using -sOutputICCProfile=my_device_profile.icc, then Ghostscript will treat the output intent as if it were the proofing profile. That is, rendering through the output intent profile and end up in the color space specified for the device profile. This use of the OutputIntent as a proofing profile will also occur if the process color model of the target device is different than the OutputIntent color space. In this sense, the "override" by the device profile is not really an override but simply an attempt to make proper use of the output intent on the target device giving the user a view of how the file was intended to look when printed/viewed on their target device. </div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="im"> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Hacks that ignore embedded profiles is what destroyed the original PNG based color management implementation. Apps wrote out PNGs with bogus color information, and when honored by viewing applications the images looked whacky. So PNG viewer application developers started to ignore the color/gamma metadata in PNG, rendering that whole paradigm entirely useless. Second guessing embedded metadata is just like second guessing actual data. Apps, RIPs, printers themselves are not ignoring RGB 232, 50, 100 in favor of some other values. They should not be ignoring embedded profiles in favor of some other values either. The mere option of overriding embedded profiles is like handing developers and users razor blades and telling them to go play out on the freeway. It will regress the consistency of color management, by making it even less consistent than it already is. </blockquote> My comment on your analogy is to say that if one doesn't know the proper way to use a tool and fails to RTFM then you deserve what you get, which is cut and run over :) . By default Ghostscript is designed to honor all the embedded color information. </blockquote> </div> kind regards Kai-Uwe<div class="HOEnZb"><div class="h5"> _______________________________________________ openicc mailing list <a href="mailto:openicc@lists.freedesktop.org" target="_blank">openicc@lists.freedesktop.org</a> <a href="http://lists.freedesktop.org/mailman/listinfo/openicc" target="_blank">http://lists.freedesktop.org/mailman/listinfo/openicc</a> </div></div></blockquote></div>