[Openicc] Color management in gimp

[Hal V Engel]

On Saturday 02 April 2005 07:59 am, Jim Gettys wrote:
> Yes, you are identifying what is missing...
>
> We need the infrastructure to store the information for input devices
> (cameras, scanners, etc.), the monitor/flatpanels, and output devices
> (printers, etc.) in a standard way and location...
>
> Then, in concert with lcms or equivalent, we will have a chance of
> convincing application developers/toolkit developers to update their
> applications/toolkits to support color management....
>
> Modularity arguments make it pretty clear the color management system
> itself should be pluggable, etc., and one component of this larger
> infrastructure....
> 				- Jim
>
snip

GIMP is making it's first steps into color management.  These appear to be 
baby steps at this point but it is starting to happen.  Have a look here 
http://developer.gimp.org/NEWS

Right now apps like GIMP, Scribus, CinePaint and GraphicsMagick are basically 
cobbling together color management because the CM infrastructure is missing.  
In reality this is how it is being done on current versions of Windows 
because the CM infrastructure as it exists today on Windows is, at best, 
weak.  So if GIMP, gimp-print, xsane... added CM awareness than we would have 
much of the same functionality as the current versions of Windows and the 
software that runs there.  I other words a CM system that has about the 
minimal functionality to be usefull in the hands of a CM savvy user.  

In that state it is not accessible to users with little or no experience with 
CM.  From what I have read the Mac's CM infrastructure is more integrated and 
more accessible.  I have also read that Longhorn will have a CM that is even 
more advanced than what is currently on the Mac.

All of this points to a progression that CM appears to go through as it 
matures on a given platform.  Right now the open source world is about where 
things were on Windows in the mid to late 1990s.  I suspect that in a year or 
two we will have some basic support for CM in X and some other basic parts of 
the infrastructure in place.  As well as a more complete set of apps that are 
CM aware like CinePaint and Scribus are today.

I firmly believe that as CM is introduced in The GIMP over the next few months 
that this will push other applications, like gimp-print and xsane, to also 
incorporate CM features.  The  reason I think this is such a big step is that 
The GIMP is on almost every open source desktop and almost everyone running 
an open source machine uses it at least occasionally.  Apps like CinePaint 
and Scribus, as nice and as powerful as they are, are aimed at a small 
segment of specialized users and therefore have little influence over what 
other will do.  Other than perhaps giving other apps a look at what is 
possible.  On the other hand The GIMP is a main stream app and other 
applications, like gimp-print and xsane, will notice that it has become CM 
aware and this will push them into also supporting CM.

In an ideal world we would allready have the CM infrastructure in place and 
apps would just need to, as Jim says, plug into it.  But this does not appear 
to be the way this naturally progresses.  On the other hand if we could get 
those who are responsible for those parts of the overall system that can be 
considered infrastructure, such X, print drivers, input device drivers, 
monitor drivers, and DEs, to get together and work out some of the 
infrastructure details it might allow the open source world to leap frog over 
parts of the early stages of that natural progression.  But I am not too 
optimistic that this will happen and I am prepared to live with the natural 
progression knowing that it is now well underway.

As a side note on Windows I use a program named ProfilePrism as part of my 
printer profiling process.  ProfilePrism uses LCMS as it's CM engine (it has 
a lcsm.dll file).   I am getting excellent printer profiles using this 
product. The reason I bring this up is to point out that this part of the 
infrastructure is very mature (maybe even world class) and it is something 
that should be leveraged as we go forward.

Hal
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/openicc/attachments/20050402/3aa5b791/attachment.pgp