[Openicc] Color management in gimp

Lars Borg borg at adobe.com
Mon Apr 4 08:34:27 EST 2005


Implementing color management as an application 
solution is not the best approach now. Such an 
approach was a necessity 10 years ago, when 
platforms provided no CM support. As a result, 
every color managed application was an island, 
with a unique culture and with few good bridges 
to other islands.

I encourage you to build a systems architecture 
where color management is inherent and mandatory 
in the platform, and not an optional, 
application-specific feature. Mac OS X has taken 
this approach. Longhorn seems to follow.

This means every color path in and out of the 
application should be tagged explicitly or 
implicitly with a color space, and the platform 
should convert as needed from the source or to 
the destination.

In such an architecture, some applications will 
be and can be color-ignorant. The platform can 
provide these applications with a consistent 
color space, such as sRGB, monitor RGB, or some 
other system default. Thus, in such an 
architecture, GIMP need not add CM, unless GIMP 
intends to support more than one color space.

(The Workflow Working Group of) ICC, chaired by 
Ann McCarthy, Lexmark, is currently working on 
defining cross-platform functional requirements 
and use cases for such an architecture. Their 
next meeting is held in London, May 3 or 4 or 5. 
I encourage you to attend. We need you there.

Lars Borg

At 10:59 AM -0500 4/2/05, 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
>
>On Sat, 2005-04-02 at 15:53 +0200, Maria, Marti wrote:
>> 
>>  Hi Paco,
>>
>>  >I wonder...
>>  >¿How can one program an efficient color management
>>  > solution if cannot insert it in the visualization
>>  > section of the aplication?
>>  >I think littleCMS as a plug-in is not a practical
>>  > solution. It does not serves at all.
>>
>>  Please keep in mind lcms, as most CMM, is only 
>>a low-level engine. It can effectively apply 
>>color transforms to a raster data. But it has 
>>no access to devices like monitor, printer and 
>>so. It is up to the application software to use 
>>the CMM as a tool to get the correct color 
>>translation before sending data to the output 
>>devices.
>>
>>  For a "good" color management in Gimp, lcms 
>>should be integrated in the core program, not 
>>only as a plug-in. There is another program, 
>>Scribus, that does that in a pretty successful 
>>way:
>>
>>  http://www.scribus.net/
>>
>>  Regards
>>  Marti Maria.
>>
>>  _______________________________________________
>>  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




More information about the openicc mailing list