[Openicc] GIMP color management
Jan-Peter Homann
homann at colormanagement.de
Mon Feb 21 00:12:04 EST 2005
Hello List
As others, I recommended, the discussion about GIMP Colormanagement
should be at this list, and not only a internal GIMP-discussion.
As doing colormanagement consulting since 15 years, I want to give some
feedback, to the LINUX community, that they may be can learn from the
CM-Implementations in Apple Mac OSX and Microsoft Windows.
Please take in consideration, that I´m not programming. So may be, the
terms I´m using are sometimes not exact the same, you are using ;-)
*******************************
A) The Main types of profiles
*******************************
There are different types of profiles:
1)Profiles for the working space
---------------------------------
This profiles are describing the color of the data, the user is
manipulating.
There are three main types of working-spaces:
1a) RGB Workingspace: e.g
- sRGB for Internet, Office... (OK for 95% of all users)
- AdobeRGB, ECI-RGB... for High-End Digital Photography and PrePress
1b) CMYK Workingspace
- e.g. SWOP coated (only needed for prepress, or Office documentes which
have to be converted for offset-printing
1c) Gray Workingspace
- e.g. Gray Gamma 2,2
It is not very common to differentiate between RGB-gray and pure gray.
But it solves a lot of problems in the colormanagement workflow, if gray
and black objects in an document can seperated from RGB-Objects.
2. Profiles for Devices
------------------------
This profiles are describing the color of the used devices:
2a) Image captuting (scanner, digital cameras)
2b) Monitorprofile
2c) printer profiles
(for every printertype, mediatype and driversetting, individual profiles
are needed
**************************
B. Main type of colortransformations
***************************
There are four main types of colortransformations:
1) Image-Capture -> working-space
All Images are converted to the actual workingspace
(e.g sRGB)
2) workingspace -> monitor
The colordata of an document is converted to the monitor
3) workingspace -> printer
The colordata of an document is converted during printing
4) workingspace->workingspace
The colordata of an document is transformed from a workingspace to
another. converting in GIMP an RGB-Image to CMYK would be such kind oft
transformation. Also during fileformat conversion, such kind of color
transformation is often used. E.G. converting an RGB Office-document to
CMYK PDF for offset-printing.
*************************************
C. Learn and make it better as Microsoft and Apple
*************************************
The succes and the traps of colormanagement at the big players are the
integration between operating system, printer-driver and application or
the missing of such integration.
1. The Microsoft approach: Force all to sRGB
--------------------------------------------
The idea and succes of microsoft-colormanagement is to force all color
to sRGB.
(As microsoft is evil to some people, the use of sRGB is also a W3C
recommandation and sRGB is an open standard without licence fees)
Drivers for imaging have to deliver sRGB-data, appplication have to do a
transformation from sRGB to the Monitor-profile. Printerdrivers have to
convert from sRGB to the printer-colorspace.
Colormanagement is completly hidden from the user. It works in the
background.
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.
So there are two things, users can not do in the microsoft environment:
- change the actual RGB-workingspace for special purposes
- use individual profils instead canned profiles for imagecapturing or
printing.
Make it better than Microsoft:
------------------------------
Mimic the microsoft-concept, but use ICC-technology would be much more
intelligent. Firstly there should be a central setting of the
RGB-workingspace at systemlevel. The default working-space should be sRGB.
- Every imagecapture application should be come with canned
input-profiles and do a transformtion to the RGB-workingspace defined at
system level.
- Every application manipulating RGB-data should display them with an
colorconversion from the system RGB-workingspace to the (canned)
monitorprofile.
- Every printer-driver should com with canned profiles for the
printertype, printing-media and driver setting. During printing, there
is a colorconversion from the system RGB-workingspace to the printer
profile.
In this scenario, the colormanagement for standard-users is completly
done in the background. There is no need to learn about profiles,
rending intents etc. But power-user can change the setting of the system
workingspace ore use individual profiles for their devices
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
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.
Make it better than Apple:
-------------------------
The graphics library for OSX is something which can serve as a
blue-print for LINUX. But still, the apple concept has some hard problems:
- intransparent to the user:
As the functions of the graphics library are relativly new, several
applications or printerdrivers have their own colormanagement.
Often they ignore the system-settings and functions. But also several
times they trigger unwanted colortransformations during printing or
fileexport, when functions of the system are used.
Even for experts like me, it is often very hard to understand what is
happen if such things appears during production.
- 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.
Having not such a mode can lead to very strange things. If a document
contains different objects (images, vectorgraphics, text objects) with
individual profiles - the same RGB-numbers in different objects leads to
differnt colors on screen or printing..
So forcing the normal user the use only very few working-spaces and
convert all contenzs to this working-space makes colormanagement much
more transparent.
*******************************************
D: How to implement colormanagement in GIMP / and LINUX
*******************************************
Don´t implement colormanagement as module inside the application
Instead:
support LINUX Graphics Library
-----------------------
Force your power to a LINUX agraphics-library which can handle bitmaps,
vectorgraphics and textobjects in RGB, Gray and CMYK. This graphics
libray should also provide color selectors for this colorspaces and ICC
transformations on all objects.
Colorconversion from workingspace to monitor should be part of the
graphics libray.
This library should provide two modes for dealing with embedded profils
in individual objects during placing them in documents:
a) "consistent-color-mode" (for all standard users):
- automatic conversion of placed content to the actual working space
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
support LINUX Colormanagement Guidelines
---------------------------------
- The profiles for monitor and default RGB, Gray and CMYK-workingspace
should be defined on systemlevel.
- The default RGB-workingspace should be sRGB according W3C
recommendations ans ISO/IEC 61966
- 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
- Applications dealing with images, graphics and text should display
colors with a conversion from the actual working-space to the monitor
profile
- If an application is trasnsforms the color of adocument from the
actual working space to a special one, the user should able to see
constantly an information, that the actual workingspace is not one of
the default working spaces on system level.
- colormanagement for printing should be always done in the
printer-driver an not in the application. So the printer-driver needs
the information about the actual workingspace of the document (either
default from systemlevel, or a special workingspace)
##########
I hope some of my experiences as colormanagement consultant are helpful
to the LINUX community.
:-) Jan-Peter
Hal V. Engel schrieb:
>
> I am taking the initiative to invite those interested in working with
> the GIMP team or following the progress of their CM project to join
> the GIMP-developer email list so that you can at least help to guide
> them away from pitfalls. And perhaps this will lead to additional
> work on open source standards for CM which would benefit everyone.
____________________________________________
> openicc mailing list
> openicc at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/openicc
--
--
homann colormanagement ------ fon/fax +49 30 611 075 18
Jan-Peter Homann ------------- mobile +49 171 54 70 358
Kastanienallee 71 ------- http://www.colormanagement.de
10435 Berlin --------- mailto:homann at colormanagement.de
More information about the openicc
mailing list