colour management system (CMS)

[Jim Gettys]

Kai,

Open source desktops need serious color management, that needs to work
end to end (from scanners and cameras, to monitors, to output devices
(film and paper).

So far we have components that are strictly worrying about one part of
the problem, and this end-to-end view has not been taken.  Some of the
existing work in the area (e.g. X's Xcms system) are myopic and only
worry about one piece of the problem (in that case, the window system,
and worse, it is 10 years out of date and almost certainly not useful at
least in its current form).

Some project like littleCMS may be serious components to solving the
e2e color problem.

The challenge therefore is to get the different projects working
together to solve the overall problem (from various applications,
to X itself, to Cairo, etc.).

So the first question is how to get all these projects to start
talking to each other to start on a complete solution, and stop
stovepiping in the individual projects.

			Regards,
				- Jim


On Wed, 2004-11-03 at 08:01 +0100, Kai-Uwe Behrmann wrote:
> Hi,
> some projects have colour management build in, based on one of the two
> freely available libraries (argyll, littleCMS). As these libraries support
> the ICC standard for colour transformations they dont facilitate
> locations, preferences and the like.
> 
> My wish is to setup an most flexible configuration system for:
> o locations, where colour profiles can been stored
> o defining standard profiles (usage)
> o setting these standard profiles system wide and as user setting
> o rendering intents and the like settings (including other switches)
> o prefered cmm (libicc, lcms, Xcms? ...)
> o prefered transformations (colour -> gray reduction, ...)
> o arbitrary content over an registration (like in TIFF or ICC standards)
> o constraints for complex settings
> o plain readable (better selfdocumenting)
> o ...
> 
> The system needs to be:
> o easily accessible by mostly all languages using the ICC libraries
> o stable over concurrent access
> o allways readable
> o extensible for text and non text caching (kind of db), maybe split off
>   into several subsystems ( device->profile, link to colour tables, ...)
> o transparent for later integration with CUPS, X, sane, ghoto
> o clear and stable for useage with device manufacturers
> 
> As well there will be an command line utility fine to show how the system
> works. I would like to start with an small C programm as most today
> programms need this in the first place.
> 
> Later can follow access from scripts and other languages.
> 
> Now my question on this list is:
> Is there an suitable configuration sheme available to fit in the colour
> management stuff? So no need for me to recreate. If not,
> what is an good starting point? One suggestion which came was XML,
> an other to look at fontconfig, which I am start reading now.
> 
> Shure the standardisation will not been made in one day as well as the
> implementation. Simply this is what I can oversee as the basics.
> 
> Awaiting Your comments.
> 
> regards
> Kai-Uwe Behrmann
>                                 + imaging development / panoramas
>                                 + color management
>                                 + email :ku.b at gmx.de
> 
> 
> 
> _______________________________________________
> xdg mailing list
> xdg at freedesktop.org
> http://freedesktop.org/mailman/listinfo/xdg