[Openicc] Color management in gimp

[Jim Gettys]

Lars,

Once the infrastructure is in place, I'd expect window system toolkits
to pick up support, bringing cm into most applications pretty directly.

The issue right now is getting the right infrastructure in place, that
will solve the problem well enough for most toolkits and applications
that it sees adoption.

I don't know if I can make it to the ICC meeting; and I'm personally
pretty clueless about color management.  We do know that the color
management done in the X library over 10 years ago is effectively
unused, and therefore not an obstacle.  It is also not clear that Xlib
is where it should be put; it may better be in toolkits in the window
system part of the puzzle.

If we take the fontconfig example, Keith Packard did quite a bit of leg
work putting together initial patches for a number of different key
systems (e.g. gtk, Qt, and others).  Someone being willing to go the
extra mile helps with acceptance, along with generating solutions that
solve everyone's problems (rather than stovepiping on a single project's
needs).
				Regards,
					- Jim


On Sun, 2005-04-03 at 15:34 -0700, Lars Borg wrote:
> 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
>