[Openicc] GIMP color management

[Hal V Engel]

On Sunday 20 February 2005 10:08 am, Jan-Peter Homann wrote:
> Hello Bob, hello list
snip
>
> 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.

My hope and think that of others on this list is see if we can apply the 
lessons of those in other environments and avoid at least some of the pit 
falls.

snip

> 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
>

I agree 100% printer profiles need to be implemented close to the device.  I 
also think this is true for input (scanner and camera) profiles.  In 
gimp-print you can setup logical printers that are really collections of 
named printer settings.  For those using gimp-print this would be a very good 
place to add the printer color management stuff.  So each logical printer 
would have it's own CM settings for profile and intent.

>
> C Testsuite / procedures
> ------------------------
> application->Monitor:
snip
> - using files with different embedded profiles should lead to different
> color appereance on monitor.

The assumption is that the profiles were assigned to the images and no 
conversion was done from one color space to another.  If a color space 
conversion has taken place then the images should have the same appearance.

>
> application->printing environment:
snip
> - using files with different embedded profiles should lead to different
> color appereance at printing output

Again the same assumption as the monitor case above applies.

snip

> 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.
>

Up until now most of the applications that have implemented CM on Linux/Open 
source platforms have been somewhat specialized or designed for smaller 
niches. The GIMP adding CM brings CM to a much wider audience and perhaps the 
next version (5.1 or 5.0.1) of gimp-print will have CM functionality.  Next 
is to get the Sane folks on board.
 
> :-) 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
-------------- 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/20050220/8bb36f44/attachment.pgp