On Saturday 15 January 2005 13:21, David Neary wrote: > Hi Gerhard, > > Gerhard Gaußling wrote: > > I'm not a Programmer, but isn't it possible to make a plug-in which load's > > the icc information at a first step, to offer the user the ability to > > decide in which way he wants to handle the file regarding it's color space? > > It would be possible to do the following: > > - load image's raw data, and ICC profile > - During display, convert from source colorspace to display > colorspace > - During saving, save the originally loaded ICC profile back to > file, if the format supports it, or convert to sRGB if it > doesnt. I am not sure that the image should be converted to sRGB if the file format does not support embedded profiles. For one thing how likely is it that someone would open an image in a file format that had an embedded profile would then save the file in a format that did not support an embedded profile. The other reason that I have for this reservation is that many of us have printers that have more gamut than sRGB supports. sRGB is OK, even preferred, for web work and for those that are working with low gamut printers, such as CMYK offset printers, but my feeling is that it is too limited for those that have wider gamut printers like the 6 and 7 color Epson or HP printers for example. That is one of the reasons that Photoshop defaults to the AdobeRGB color space, which is a medium wide gamut color space, as this has enough gamut to fully support these wider gamut printers. If the GIMP is going to use a default color space this should not be a low gamut color space like sRGB. On the other hand anyone working with image file formats that do not support embedded profiles should have color management turned off. So perhaps someone can convince me that this is the correct thing to do. I think it would be useful for this list to talk about how The GIMP will work with color management turned on and with it turned off. As these 2 configurations will be used by users that are working at very different levels of expertise and with significantly different expectations. > > The problems with that approach are > > - Lots of elements in the GIMP are not colorspace aware - for > example, you would have to modify the paint tools to detect > whether there was an ICC profile associated with a display they > were painting to, and color convert the (sRGB) data that they > are painting. This is not possible currently, and Sven has > expressed a desire that color management be kept out of the > core in the past. At this point nothing in The GIMP is color aware other than the proofing plugin. So should every plugin need to do color conversions to the display color space or should this be handled in one place? Since current plugins know nothing about color management and color spaces should we be making assumptions about what color space these are working in (some plugin authors may have assumed sRGB but have all of them)? Since I have not looked at the code I do not know what should and should not be in the core. But perhaps some color management functionality belongs in the core. But I will let those that know how the application is structured work this out. But it seems to me that the core could have a high level color management interface that abstracts this to hide the specific implementation details. Then the core could map these to a specific implementation using LCMS, Argyll or some other CMS library. Perhaps this is what Sven had in mind. > - Data which enters the image from other sources (copy & paste > from another image, for example) may have been in a different > colorspace, requiring convertion or some other funkiness to > keep things coherent inside the image Yes is is exactly correct. When we copy from image A in color space X to image B in color space Y the image data coming from A must be converted from color space X to color space Y. To do anything else would not be correct. > > > After this step the file will be converted into the choosed colorspace[*] > > and then loaded into the gimp, displayed in the working colorspace, > > corrected by the monitor profile, with the possibility to choose a "color > > proof view" with a selectable icc profile for the soft proof. > > We currently have the ability to do color proofs with external > ICC profiles. THe interface to the loading of the profiles isn't > perfect yet, but it's there. > > Cheers, > Dave. > > -- > David Neary, > Lyon, France > E-Mail: bolsh@xxxxxxxx > CV: http://dneary.free.fr/CV/ > _______________________________________________ > Gimp-developer mailing list > Gimp-developer@xxxxxxxxxxxxxxxxxxxxxx > http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer >
Attachment:
pgpHPp0YDBVo0.pgp
Description: PGP signature
