[Openicc] Is CUPS the right place .... we don´t need a ICC czar...

Mon Feb 7 13:44:13 PST 2011

Hello Edmund, hello list
I think the problem we have in the color management is not the case, 
that the ICC-standards defines a precalculated profile format and all 
problems will get solved magically, if we switch to a measurement based 
profiling approach.

The core of the problem is define a framework, how documents, 
applications, shared libraries and printer drivers interact concerning 
profiles. If this failes with ICC-profiles, it will also fails with a 
measurement based profiling approach.

Currently, I see the discussion at the OpenICC mailinglist and the 
OpenICC wiki on a good way to solve the puzzle:

- Define printer driver settings and related ICC profile for each 
setting on driver level (e.g. Gutenprint or Turboprint
- Update a "Linux Color Manager" like e.g. Oyranos or g-c-m with driver 
settings / ICC profile relations
- Create a link betwen the driver settings and the User Interface (e.g. 
Common Print Dialogue CPD)
These parts are necessary, so that the user just choose in CPD the 
desired print setting and the matching ICC-profile will be configured 
without any need of manual configuration.

Now we need to deliver also the profile of the document into the 
printing workflow. This could e.g. solved, if  documents and 
applications can opt-in into Oyranos or g-c-m to provide the current 
active document profile. If we use PDF as format for the spool file, the 
document profile will be embedded as output intent.

The last information which optionally can be defined by the user in the 
printing UI (CPD) is the rendering intent from document profile / output 
intent to the printer setting profile. If the user doesn´t define the 
intent, it will be relativ colorimetric with blackpoint compensation).

The PDFtoRaster engine like e.g. GhostScript is now complety automatic 
configured for color matching.
(Use Output Intent as source profile and printer setting profile as target)

(By the way the conversion method "relativ colorimetric with blackpoint 
compensation is already a simple measurement based app

best regards
Jan-Peter

Am 07.02.11 16:50, schrieb 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
>>
> _______________________________________________
> openicc mailing list
> openicc at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/openicc
>

-- 
----------  Please note the new adress --------------

homann colormanagement --------- fon +49 30 611 075 18
Jan-Peter Homann ------------ mobile +49 171 54 70 358
Cotheniusstr. 3 -------- http://www.colormanagement.de
10407 Berlin -------- mailto:homann at colormanagement.de