[Openicc] GIMP color management

Francisco Bernal Rosso pacorosso at ono.com
Mon Feb 21 10:11:29 EST 2005


I see the program in this way:

A central part which coordinate the translation of color mean beetween
different color spaces with this changes.

Read the photo data (original image profile or not profile at all)
translate the photo data (RGB numbers) to an independent device -neutral-
space (maybe some of what adobe call "workspaces" -Adobe RGB, ColorMatch,
eciRGB, sRGB- or some real color definition mode as Lab)
Translate the photo data to screen color space (via the screen profile)
Translate the photo data to the output device color space.
And (this is the reason I write now) a device link profile which make a
translation from the neutral space to the output device AND THEN the data
sended to the output device to the screen color space. This is to achieve a
"soft proof" of the output device. So I see it is important to have a kind
of "out of gamut" warning.

----- Original Message -----
From: "Jan-Peter Homann" <homann at colormanagement.de>
To: "Bob Friesenhahn" <bfriesen at simple.dallas.tx.us>
Cc: "OpenICC Liste" <openicc at pdx.freedesktop.org>
Sent: Sunday, February 20, 2005 7:08 PM
Subject: Re: [Openicc] GIMP color management


> Hello Bob, hello list
> Working with digital color since the late 80ties on AMIGA and later
> focused on Mac OS and Windows (if not avoidable...) let made me
> following experience:
>
> In the field of colormanagement, programmers of applications, OS and
> printing environments often invented the wheel several times itself. At
> the end the user had a car with 11 wheels of different sizes and needed
> a mechanican to make it driving.
>
> Observing the development of LINUX, it seems that the community needs to
> make the same experiences...
> A definition of expected behavior and a testsuite seems to be a very
> good idea to lead the user through the jungle of different environments.
>
> What are the basics from my view:
>
> A) Central place incl. chooser for:
> ----------------------------
> - Monitor profile
> - RGB-workingspace profiles
> - CMYK-workingspace-profiles
> - standard CMM (littleCMS, Argyllcms)
>
>
> B) Definitions of expected behavior:
> ---------------------------------------
>
> An application / library should be use
> - monitor profile
> - RGB-working space profile
> - CMYK workingspace profile (if necessary for the intended use)
> - standardCMM
> - embedd the actual working space during file-save
> - use an embedded profile during file-save
>
> A printing environment should be use
> - RGB workingspace for RGB-files without embedded profile
> - CMYK workingspace for CMYK-files without embedded profile
> - use embedded profile instead default working-space
> - standardCMM for color transformation to the printing colorspace
> - the profiles for the printer should be connected to the settings for
> printertype, printing media, other driver settings
>
>
> C Testsuite / procedures
> ------------------------
> application->Monitor:
> - Changing between very different monitor-profiles on system level
> should lead to different color appeareance on monitor
> - changing between differnt working spaces on systemlevel should lead to
> different color appereance on monitor (for files without embedded profile)
> - using files with different embedded profiles should lead to different
> color appereance on monitor
>
> application->printing environment:
> - Changing between very different printer-profiles (in the printer
> driver) should lead to different color appereance at printing output
> - changing between different working spaces on systemlevel should lead
> to different color appereance at printing output (for files without
> embedded profile)
> - using files with different embedded profiles should lead to different
> color appereance at printing output
>
>
> This would be some easy tests, if applications / libraries and printing
> environments are able to recognise central color settings on system
> level and embedded profiles in files.
>
> As the profiles on system level are connected to the standardCMM, the
> proper use of intents and profiles itself can tested seperatly.
>
> If somebody plans to make such testsuite, I would be able to deliver
> profiles, which leads to very different visual appeareance.
>
> ---
>
> Some time ago, the gimp-print team announced at the colorsync
> mailing-list, that they plan to implement more colormanagement
> functionality.
> In my view, it would nice, when both GIMP and GIMPprint can use a
> system-setting for RGB- and CMYK-workingspace, a standardCMM on
> systemlevel and communicate together. This would may lead other teams
> also to use this mechanics instead of inventing their own
> colormanagement-wheel.
>
>
> :-) Jan-Peter
>
>
>
> Bob Friesenhahn schrieb:
> > On Sun, 20 Feb 2005, Jan-Peter Homann wrote:
> >
> >>
>   The best we can hope
> > for is a an application agnostic framework or library which can be used
> > to enhance existing rendering environments with color management.  Even
> > if this is not achieved, a standard of operation and a standard way to
> > install color profiles and describe the local color management
> > intentions/process would be a great benefit to the community. A
> > compliance test suite (inputs and expected output) would also be a
benefit.
> >
> > Ultimately the user should not need to care if she is using Gnome/Gdk,
> > KDE/Qt, gimp-print, VTK, OpenGL, ImageMagick, libart, imlib, GD, X11,
> > Ghostscript, Mozilla, SVG, CinePaint, GIMP, or any other combination of
> > software environments.  As long as there is a definition of expected
> > behavior, and verified compliance to that definition, then the user can
> > expect correct behavior.
> >
> > Bob
> > ======================================
> > Bob Friesenhahn
> > bfriesen at simple.dallas.tx.us,
http://www.simplesystems.org/users/bfriesen/
> > GraphicsMagick Maintainer,    http://www.GraphicsMagick.or
> > g/
> >
> >
> > ------------------------------------------------------------------------
> >
> > _______________________________________________
> > openicc mailing list
> > openicc at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/openicc
>
>
> --
> --
>
> homann colormanagement ------ 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
>
> _______________________________________________
> openicc mailing list
> openicc at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/openicc




More information about the openicc mailing list