[Openicc] colord Printing Plans

[Michael Vrhel]

DeviceRGB is not "mapped" to sRGB.   One has to define DeviceRGB to be 
something though.  Especially if you have varying RGB target devices.  If 
your target device is an RGB device and you have DeviceRGB coming in, then 
it is straight forward to make sure the source DeviceRGB values are not 
"touched" by having the source and destination profiles the same in your 
set-up.  In this case, ghostscript will not do anything to the DeviceRGB 
values.   The same logic is true for DeviceCMYK source values on a CMYK 
device and DeviceGray source values on a Gray device.   The point is you are 
in complete control over how DeviceRGB, DeviceCMYK and DeviceGray values are 
interpreted by ghostscript.

Michael

-----Original Message----- 
From: edmund ronald
Sent: Friday, February 25, 2011 12:39 AM
To: Open ICC Color Managment
Subject: Re: [Openicc] colord Printing Plans

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