[Openicc] Linux colormanagement recommendations

[Jan-Peter Homann]

As an colormanagement consultant with focus on MacOS X, Adobe 
applications and proofing solutions, i´m still learning about LINUX.

I will try to make a first concept how I would wish color management 
implementation under LINUX.


GTK+/Gnome versus QT/KDE based applications
--------------------------------------
Both GTK+ and QT give programmers basic routines for displaying 
primitives like bitmaps, vector-elements and text on the monitor.
Both GTK+ and QT don´t support any form of color management with 
ICC-profiles.
If an programmer makes his own solution for using colormanagement in a 
QT based environment like the Scribus project, a GTK+ project like GIMP 
can not use the QT based solutions.
If color management is applied to GTK+ and QT based applications, they 
will use littleCMS.
So it make sense to place littleCMS in an OS-layer under GTK+ or QT, 
that both worlds can use color management.
In a next step there should be some recommendations, how the littleCMS 
can be used from QT and GTK+ based applications. For QT we have now with 
Scribus a reference implementation. For GTK+, I don´t know if there is 
something comparable.

Systemwide colorsettings and profile locations
----------------------------------------------
In color management, it is necessary to understand the difference 
between profiles for working colorspaces and device colorspaces.
Working colorspaces are describing a standard colorspace for the 
exchange of all kind documents. The most used working colorspace is sRGB 
  for RGB documents, or printing standard like SWOP for CMYK documents.

Device colorspaces are describing input and output devices like scanner, 
monitor or printer/paper combination.

A simple sRGB based colormanagement workflow defines, that all RGB-data 
is sRGB. In this case all input applications like scanning softwares are 
converting the data form scan-RGBto sRGB. For displaying at the monitor, 
the RGB-data is converted from sRGB to monitor RGB.
This transformtion should be done on the level of GTK+ or QT, that not 
every programmer itself has to implement colormanagement by himself.
At the output side, GIMP Print or a similar programm is converting the 
RGB from sRGB to the printer-colorspace.

Implementing the sRGB to monitor-RGB conversion in GTK+ and QT would be 
the biggest step to integrate colormanagement systemwide.
There should be a central location for profiles both for working 
colorspaces and device colorspaces.

The central colorsetting for this simple workflow would be called 
"sRGB-workflow".

If this work has been done, the next step would be the possibility to 
change the Profile for the workingspace to another profile like AdobeRGB 
, ROMM-RGB or ECI-RGB which are useful for digital imaging, because sRGB 
has in the field of cyan and blueish greens and for dark saturated 
colors a smaller gamut then a lot of printer spaces.

The central colorsetting would be called AdobeRGB-workflow.
An ideal scanning application or print application would automacticly 
change the profile for the working space, if this has been done in the 
central colorsettings.
During scanning or printing, the user should be able to see, what 
workingspace is actual used (sRGB, AdobeRGB etc...)

The need for colortransformations of files and documents
--------------------------------------------------------
There are several cases were color transformations of files or documents 
are needed. Typical is a RGB to CMYK conversion, when RGB files or 
documents are prepared for printing. Another Transformation is one 
between different RGB working spaces,
Such conversions should be implemented on systemlevel and not direct in 
the application.
So, if a programmer needs to convert TIFF, JEPG, SVG, PostScript or PDF 
from sRGB to CMYK or from AdobeRGB to sRGB, he just calls the 
system-routine.



Implementing a Softproof on Systemlevel
--------------------------------------
If an application based on GTK+ or QT is able to display sRGB-Data via 
ICC to monitor-RGB, it is just a function of the littleCMS to simulate a 
transformtion at the monitor.
In this case a user would work in sRGB and could simulate the 
colortransformtion to CMYK or another RGB-workingspace at the monitor.

This feature called "softproof" should be part of the central color 
settings.

For GIMP this would be first step to CMYK without the need to rewrite 
the whole application.


Integrating the CMYK colorspace at systemlevel
-----------------------------------------------
If there are modules for GTK+ and QT for matching different RGB- working 
spaces via ICC to the monitor-RGB, it is not a big step to match CMYK 
via ICC to the monitor.
So integrating CMYK as an alternate colorspace to RGB for primitives in 
GTK+ and QT should not be a big step.
Also a CMYK color selector should be available at systemlevel.

The colorsetting for the CMYK workingspace should be available on the 
same place where the RGB-workingspace is choosed.


Scribus / QT as reference implementation
------------------------------------------
As I actual understand, Scribus has already implented most of this 
features for QT based applications. So the next step would be to make 
some kind of libraries or modules for QT based applications, that other 
programmers can use this fuctionality for their own applications.

I would suggest 4 libraries or modules:
1) match RGB-data from sRGB or other profile to the monitor-RGB, use 
softproof of a colortransformation if you want
2) colortransform different fileformats via colormanagement
3) Display CMYK objects via ICC at the monitor
4) Define and manipulate CMYK objects

The littleCMS, the place for profiles and the central colorsettings for 
such libraries/modules should be implemented on a systemlevel, that both 
QT and GTK+ appplications can use it.

If some GTK+ programmers want to implement color management, they can 
use Scribus / QT as a blueprint


I hope some of my ideas are helpful.

:-) Jan-Peter


-- 

colormanagement.de ---------- 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