[Openicc] colord Printing Plans

[Chris Murphy]

Unless the PPD for the printer says otherwise for ICC based color management, I don't see how we can second guess this and not submit /DeviceRGB untouched to PostScript printers if the application is spitting out /DeviceRGB PostScript. They have built-in CSAs and CRD's that will assume sRGB and convert to an internal CMYK space as the manufacturer designed it. If the results are nasty, well, it's the manufacturer's fault.

Chris


On Feb 25, 2011, at 1:50 AM, peters at skarpetis.com wrote:

> DeviceRGB should be left alone for the cases where the output is RGB. For other output colourspaces a default, such as sRGB, should be assigned. 
> 
> Peter Skarpetis
> 
> On 25/02/2011, at 7:39 PM, edmund ronald <edmundronald at gmail.com> wrote:
> 
>> Why would we wish to remap DeviceRGB to sRGB?
>> WTF is going on here?
>> Can somebody please make a flowchart of color policies that makes
>> sense so we can all agree on some base rules?
>> 
>> Edmund
>> 
>> On Fri, Feb 25, 2011 at 12:14 AM, Gerhard Fuernkranz <nospam456 at gmx.de> wrote:
>>> Am 24.02.2011 23:09, schrieb Chris Murphy:
>>>> And in the case of RGB content being printed to a PostScript device, the content is color managed before it gets turned into PostScript.
>>> 
>>> When printing from dumb applications which are not color management
>>> aware, this is unfortunately not the case. IMO most applications still
>>> produce DeviceRGB Postscript files (actually "untagged" RGB, but as
>>> there is no "UntaggedRGB" defined in Postscript, they use DeviceRGB
>>> instead). A simple pass-through would either treat the DeviceRGB as
>>> printer RGB (in case of a printer driver with RGB ProcessColorModel), or
>>> result in an UCR-based DeviceRGB -> DeviceCMYK transformation in the
>>> RIP, as defined by the PLRM, which is certainly not what we want either.
>>> Somewhere these DeviceRGB colors still need to be remapped (e.g. to
>>> sRGB) and transformed to the ICC-based printer color space.
>>> 
>>> So I'm wondering, what are arguments against generally supplying the
>>> desired DefaultRGB/Gray/CMYK profiles, and the printer profile as output
>>> profile to ghostscript, and then feeding gs either with the PS or with
>>> the PDF document to be printed, in order to produce the raster file,
>>> implicitly getting more or less full PS and PDF color management (except
>>> for potential bugs/limitations still present in the current
>>> implementation)? [still all options are open; DefaultCMYK can be of
>>> course also set to /DeviceCMYK if printer CMYK passthrough is desired,
>>> or one could set DefaultCMYK to say ISOcoated, for re-targeting PS and
>>> PDF files intended for a press to the printer]
>>> 
>>> Regards,
>>> Gerhard
>>> 
>>> _______________________________________________
>>> openicc mailing list
>>> openicc at lists.freedesktop.org
>>> http://lists.freedesktop.org/mailman/listinfo/openicc
>>> 
>> _______________________________________________
>> openicc mailing list
>> openicc at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/openicc
> 
> _______________________________________________
> openicc mailing list
> openicc at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/openicc