[Openicc] GIMP color management

[Graeme Gill]

Some random comments/suggestions in reaction to
Jan-Peter Homann's email:

> 1. The Microsoft approach: Force all to sRGB
> --------------------------------------------
> The idea and succes of microsoft-colormanagement is to force all color 
> to sRGB.

I think you are drawing too broad a conclusion about Microsoft/Windows.
There are several elements:

* The OS provided resource ICM2.0.
* The Microsoft and printer vendor supplied print drivers.
* Microsoft applications.

ICM2.0 is a very similar resource to Colorsync (they came from the same
supplier, Heidelberg), and is neutral about sRGB, it's just mechanism,
it doesn't determine policy.

Almost all the usually supplied print drivers are RGB, because Microsoft's
native imaging model (GDI) is RGB, but I understand it's possible to
run GDI print drivers in CMYK if you know how (just noone bothers), and it's
certainly possible for Postscript & PDF drivers to run CMYK and other
colorspaces (that's what my former employers Colorbus Cyclone product has
done for many years on a Windows platform.)

All the Microsoft supplied applications are RGB only (as far as I know),
and convert everything to RGB as a working space. Other applications
do not (ie. Photoshop etc.).

So, nothing about the underlying platform or even ICM2.0 compels
sRGB, but many applications and print drivers assume RGB.

And don't forget Michael Bourgoin and Michael Stokes are at Microsoft,
working on a new Windows Color Architecture (WCA) for Longhorn and beyond,
that fully addresses all these issues and goes well beyond Colorsync -
see 
<http://download.microsoft.com/download/1/8/f/18f8cee2-0b64-41f2-893d-a6f2295b40c8/TW04034_WINHEC2004.ppt>
and 
<http://download.microsoft.com/download/1/8/f/18f8cee2-0b64-41f2-893d-a6f2295b40c8/TW04035_WINHEC2004.ppt>

> The problem of this concept is, that it is not based on the open 
> ICC-standard. So every vendor is free to implement is own technology for 
> converting images to sRGB and to convert sRGB-colors during printing to 
> the printers space.

ICM2.0 is based on ICC, just like Colorsync.

> - use individual profils instead canned profiles for imagecapturing or 
> printing.

A standard Windows Epson print driver lets you select
what (RGB) profile you would like to use for printing, etc.

> input-profiles and do a transformtion to the RGB-workingspace defined at 
> system level.

It's actually a bad thing to do a color conversion when you don't have
to. You loose information (ie. gamut, black generation) and add artefacts
(quantization noise, table resolution noise, color transform inaccuracy etc.),
and have to apply a gamut mapping policy (rendering intent).

If your intention is to manipulate pixel values, and your manipulation
algorithms have to work in a certain space (or you are merging images
in different color spaces), then converting to a working space is
a necessary thing. If the image is just passing through, then don't convert it,
leave it alone. That's the whole idea of tagging/embedding profiles in images
or other graphics elements.

> 2) The Apple approach: colormanagement-power in the OS
> -----------------------------------------------------
> The idea of Apple is to put most functions for imaging and 
> colormanagement into OSX. The graphics-libraries are can handle bitmap 
> and vector graphics in RGB and CMYK incl. icc-based colortransformtions 
> for all obcjects to the monitor, to the printer and for fileconversion. 
> Color selectors for RGB and CMYK are part of the OS.
> Generating, displaying, converting and printing PS and PDF-files is part 
> of the OS

I'm not convince Apple OSX is much different to Windows. Colorsync and ICM2.0
are very similar. Quartz has the ability to cope with all the PDF like colorspaces,
(hardly a surprise since Quartz is a PDF like rendering system) including
CMYK, L*a*b* etc., but doesn't seem to have DeviceN, so it seems better than GDI,
but a subset of what is being promised for WCA.

> For programmers, which plan to make new applications for the graphics 
> arts, apple OSX is a dream. A lot functions which would have to be coded 
>  by them self on other platforms, are just standard-calls to the 
> graphics library.

Agreed that Apple has a nicer rendering library in Quartz, than
Windows has in GDI.

> - No "consisten-color-mode"
> The apple OSX allows, that in a document every image, every 
> vector-object and every text-object can have its own profile and 
> rendering-intent. Making a PDF from such a document and place it in 
> another document, which has his own working-space increases the 
> complexity of colormanagement exponential.
> A "consitent-color-mode" which forces the user to have only one 
> working-space for the actual document prevents a lot of the complexity 
> problems of colormanagement.

Working spaces are very application dependent. A sophisticated application
may not need to use a working space, it may be able to apply the
transformations it wants in any tagged colorspace, so forcing a single
working space on all applications is not a good idea. A user set default
working space would be a good idea, so that it doesn't have to be configured
for each application that chooses to use a working space.

PDF is designed to have each element tagged with its own colorspace,
with the rendering into a single colorspace deferred to the last
possible point ("Late Binding", embodied in the PDF/X-3 concept.)
Combining such documents is easy, each element retains its own
tags.

"Rendering intent" has become an overused label I think, confusing
between the tagging of what's important about a particular
element (ie. "it's a photograph", "it's a business graphic", "it's
printed text", "it's a logo color"), and the type of gamut mapping
that should be performed during a color transformation
(ie. "retain relative color values and a pleasing color reproduction",
"retain vibrant colors", "use black ink only for CMYK output", "retain
colorimetric value" etc.). It would be good to keep these two
concepts separate in a future looking color architecture, as we
move away from the "smart profile, dumb CMM" approach assumed by
current ICC, to the "dumb profile, smart CMM" approach that gives
superior results, and is more tractable with current computing resources (WCA
is very much based on this proposition). In the former, since gamut mapping was tied
into the profile, and profiles are tagged to the images, the two get confused.

I don't think there is anything magical about having color "in the OS".
It just needs to be a general resource for transforming colors, that
applications can rely on being provided. This is not too different to
saying that it's good if stdio is provided with all systems.

Of course the next step is to have some centralized record of
what device profiles are associated with each color device, what
defaults should be used as working space, un-tagged color handling etc.,
to avoid each application doing their own thing, forcing
the user to configure the same information over and over,
and of course it's nice if there is a universal graphics
rendering library available that talks to all of this,
to again avoid each application writers inventing the wheel again.

> a) "consistent-color-mode" (for all standard users):
> - automatic conversion of placed content to the actual working space

I'm not sure this is workable. It can be "made" to work, but color
conversions have many side effects, and a proportion of users
will not cope with the side effects. That proportion is often
those that have any interest in the color of the result.
Note that within Quartz, the color handling is not made invisible,
it is part and parcel of dealing with graphics rendering. The
programmer (the "user" of a color system) has to cope with it, and
coping with it is made as painless as possible. How they present it
to the end user is therefore an application dependent thing, and
has little to do with the underlying system libraries or OS.

> b) "mixed-color-mode" (only for colormanagement-power users):
> Opening of a dialoguebox: This objects has an embedded profile different 
> to  the actual workingspace what to do:
> -- convert to actual workingspace
> -- place object and preserve embedded profile

I think we need to make a clear distinction between system
resources ("mechanism"), system policy, and application policy.
The latter can only be guidelines from a system providers point of
view, since it's largely up to the application writer.

> - The profiles for the image capture devices should be part of the 
> image-capture driver
> - The profiles for the printer should be part of the printer-driver and 
> be automaticly assignd to settings for printer-typ, printing-media and 
> other driver-settings
> - Image capture applications should do a ICC-conversion from 
> Input-colorspace to the Default working space from the system

Keep in mind the complications of calibration (ie. display calibration
via RAMDAC Luts or DDC, printer calibration via device curves or
more sophisticated methods etc.), and that often the profiling will
depend on details of the rendering system, e.g. screening and possibly
a separate separation step for multi-ink printers. If you have only
one printing system, it's not too bad, but if you have several
alternate printing or other device driver systems (CUPS, GhostScript,
Printer Vendors drivers, 3rd party applications), scanning front ends
(SANE, Vuescan, scanner vendors drivers, 3rd party applications),
graphics rendering systems (X11, direct frame buffer etc.), there
could be some challenge in organizing things in a useful way.
Things like printer configs tend to drive an exponential number of
required profiles, only a few of which are likely to actually be
available. A calibration system can soak up some of that, but coming
up with something flexible and useful will be interesting.

> - Applications dealing with images, graphics and text should display 
> colors with a conversion from the actual working-space to the monitor 
> profile.

A nice architecture is one with flexibility, and not too much policy
hard coded into it. If the color being sent to the display is suitably
tagged, then this should all get taken care of. The display driver
(ie. X11) knows what the display profile is from the users central
color configuration. An application tags it's colors appropriately, eg.:

1) DeviceRGB or Display Profile:- the application has done the conversion
    (or is characterizing the display), and the display driver does nothing.

2) Other Device Profile or device independent colorspace :- the display
    driver does the conversion to the display colorspace, using whatever
    other tagging is given to guide gamut mapping.

A printer driver would operate similarly. This is along the lines of
minimizing the number of color conversions, and leaving binding as late
as possible, to minimize multiple gamut renderings loosing gamut, or
distorting the end result.

Graeme Gill.