[Openicc] Is CUPS the right place for printer color management...

[edmund ronald]

Why do you people want to put a hack on a hack on a hack?
CUPS is not going to get any nicer.
And the nightmare of having several instances of local and remote CUPS
with different versions - who color manages what?

I think we have two choices here:

1. Appoint a Color Czar who will make ICC color management work, and
everyone liaises with him/her. I get to vote for Gutenprint, and I can
say that we will be delighted to work with whoever it is, but we won't
integrate color conversion/profile application code directly into
Gutenprint because the color-specific programming expertise is not
there.


Or

2. We sit down and we actually create a non-ICC architecture eg. the
one I suggested where original data in a colorimetric space is passed
around from app to app. This would mean that each app could then
independently obey instructions to do something with the color
information; eg. a print preview for different papers could still
easily be generated by an app that would intercept a CUPS queue. A
screen manager could decide how to show color data on screen. At the
edges of this system it would be ICC conformant in the sense that it
would accept color data in standard workspaces, and could apply
printer profiles.


I don't think we can recreate an ICC-only system without a color czar
because ICC is destructive of color data, and thus at any point if a
choice is made upstream it cannot be undone easily.

Edmund
Edmund



On Mon, Feb 7, 2011 at 3:50 PM, Kai-Uwe Behrmann <ku.b at gmx.de> wrote:
> Am 07.02.11, 14:15 +0100 schrieb Jan-Peter Homann:
>>
>> ... and if not, where is the place ?
>>
>> hello list,
>> I try to understand, the ICC-related options in in CUPS, but I still feel
>> lost. May somebody can help or correct me:
>>
>> cupsICCProfile
>> ***************
>> http://www.cups.org/documentation.php/doc-1.4/spec-ppd.html#cupsICCProfile
>>
>> Comment Jan-Peter Homann:
>> This PPD attribute delivers a possibility in the printing GUI to specify
>> an ICC profile for the driver setup by keywords like e.g.
>> ColorModel.MediaType.Resolution/Description
>>
>> As CUPS is not able to perform ICC based transformations itself, this
>> functionality is helpful for an external filter to identify the correct
>> printer ICC-profile for the choosen driver setting
>>
>> cupsRenderingIntent
>> *********************
>> http://www.cups.org/documentation.php/doc-1.4/spec-raster.html#TABLE2
>>
>> Comment by Jan-Peter Homann:
>> Extremly poorly documented feature. It may allow to specify a
>> RenderingIntent for an ICC based color conversion from the document
>> colorspace to cupsICCProfile. (Or it is may means something complete
>> different...)
>>
>> Implementing Color Management
>> *********************************
>> http://www.cups.org/documentation.php/doc-1.4/raster-driver.html#COLOR
>>
>> Comment by Jan-Peter Homann:
>> This text describes NOT how to implement Color management with CUPS. It
>> only describes the part of specifying a selector to printer profiles with
>> cupsICCProfile.
>
> That much reflects my opinion, that Apples colour management is not much
> exposed through CUPS or its documentation. We see merely some hooks. To base
> a complete architecture on this material or blindy copy & paste it is the
> wrong way. Consequently the RedHat attempt, while applaudable that they care
> about colour management for printing, appears currently like a dirty hack.
>
>> Conclusion
>> ***********
>> So far as I understand, the main idea of color management in CUPS is
>> framework for PPD-options to select printer profiles in the directory
>> /usr/share/cups/profiles.
>> If the CUPS profile selector should be linked with settings of the printer
>> driver (e.g. Gutenprint) it is the responsibilty of the driver vendor to
>> create the link.
>> cupsICC also allows to define individual Keywords through
>> cupsICCQualifier2 and cupsICCQualifier3
>> to be defined in the PPD.
>> This could e.g.
>> "mediatype"
>> "NameOfDriverSetting"
>> If the special settings are specified in the driver, this allows to
>> organize the driver settings according mediatypes.
>>
>> CUPS delivers only a mapping of Printing-Device/Setting to ICC-profiles.
>> If such mappings are managed outside CUPS e.g. via Oyranos or Gnome Color
>> Manager, it is not a must for ICC aware print workflow usind CUPS as
>> transport mechanism.
>> For the enduser, the presentation of different printer driver settings
>> from e.g. Gutenprint in the Printing UI could be realized without  CUPS
>> through the LINUX OpenPrinting Dialogue as an individual option.
>>
>> Workflow with cupsICC:
>> - Driver-Vendor, Media-Vendor or User creating driver settings with
>> attached ICC-Profiles
>> - The generic Driver PPD is updated with entries for cupsICC according the
>> settings
>
> This model needs root access. We should avoid making this a requirement for
> user supplied profiles.
>
>> - Oyranos or g-c-m parse cupsICC in updated PPD and know, which profile
>> belongs to which driver-setting
>> - The enduser sees the different driver settings according the updated PPD
>> in the print dialogue
>> - Choosing a driver setting signals Oyranos or g-c-m the current valid
>> printer profile, which configures the ICC transformation from document
>> colorspace to the printer profile in the preferred toolkit
>>
>> Workflow without cupsICC
>> - Driver-Vendor, Media-Vendor or User creating driver settings with
>> attached ICC-Profiles
>> - The driver has a direct link to Oyranos or g-c-m
>> - Oyranos or g-c-m create an Option in the OpenPrinting Dialogue
>> - Choosing the Option in the print dialogue signals Oyranos or g-c-m the
>> current valid printer profile, which configures the ICC transformation from
>> document colorspace to the printer profile in the preferred toolkit
>
> I think a lot of the discussion goes around, where the profile selection
> shall happen and how many informations need to be transported to and from
> CUPS server. With the profiles selection in CUPS server, many relations
> appear fuzzy like: who owns the job, can CUPS access the settings of that
> user, remote access issues, will proofing and calibration work relyable ...
>
> The other path is a early profile selection inside a UI (CPD). This includes
> the need to transport that profile and belonging settings to CUPS server and
> its helpers (Ghostscript/Gutenprint). Opt out and preview could be coded
> much easier. If a administrator or vendor wants to set one specific ICC
> profile to a queue its still possible through the cupsICC path.
>
> Thats of course some more work than just to replace the Apple code in CUPS
> server, but in the end a flexible one. It will cover a lot of use cases.
> Maybe we can make this a GSoC project: "Colour management near CUPS"
> Please note, _not_ inside CUPS.
>
>
> kind regards
> Kai-Uwe Behrmann
> --
> developing for colour management www.behrmann.name + www.oyranos.org
>
> _______________________________________________
> openicc mailing list
> openicc at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/openicc
>