Hello David, BTW: Using the gmane.org newsserver and a news client seems to be a good alternative to the mbox archive ;-).
David Neary wrote: > [...] > 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 If you apply a conversion to the file there will be a loss of color information, so it's necessary, that we avoid unneeded conversions to the original file. For example, if you convert from adobeRGB into sRGB and viceversa several times, you wouldn't receive the original color impression never more, it's lost, and there for in poor quality (comparable with the jpeg lossy compression, keep that in mind). So, we have to convert only the displayed version of the data, not the original data (Jan-Peter, Hal and others, please correct me if I'm wrong). This is important, to get a display color as closed to the original scene in nature as possible, adjusted to the display hardware by the measured or proofed monitor profile. While rendering the data for the display this way, the data itselves stays in working color space, or original color space (as choosen by the user while opening the file). It should be saved with the working color space e.g. as device independant suggested by ECI.org eciRGB.icc, which is comparable with widegammut and adobeRGB, or the original color space (as choosen by the user while opening the file), to avoid unneeded conversions while saving the data. eciRGB.icc offers a wider range of colors compared to sRGB, which got a very limited color space, so it avoids clipping, when converting e.g. from scanner profiles to the working color space. The user should archive the data in the recommended device independent colorspace (e.g. for Europe according to the suggestion of the ECI in eciRGB color space [1]). To Print the data it should be converted to the printer profile (This should happen in the service bureau or the printer service, maybe the printer offers you the printer-device profile to do the conversion by yourself. At home you can measure your inkjet profile for example, and apply that.) If you want to save your work for web you should do that by using the conversion from (the wider) working color space to sRGB the default for webpublishing. > - During saving, save the originally loaded ICC profile back to > file, if the format supports it, or convert to sRGB if it > doesnt. This all should be flexible and interactive (there could be an easy mode coosen in the preferences to disable colormanagement at all), and it's important to retain as much original color informations than possible. > > 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. Okay, so I assume, that my (and Hal's and Jan-Peter's) suggestions have to wait for the release after GEGL? For a new rendering-engine further to GEGL? GIMP 3.0? I want only remember the developers that there is already a state of the art color-management used by the printing industry, which the GIMP-developers can't ignore while implementing colormanagement and CMYK or multichannel/DeviceN mode for the GIMP. Just avoid to go into the wrong direction when going further with the implementation of colormanagement. > - 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 Photoshop lets pop up a dialog where the user can decide the kind of conversion he will do for the pasted/dragged image. >> 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. Desired is a 'On the fly' Softproof. I admit, that this is a very complex subject, and it is much work to implement all this color stuff into the GIMP, but I'm shure it's worth it. Thank you Gerhard [1]http://www.eci.org/eci/en/044_working_colour_spaces.php http://www.eci.org/eci/en/021_goals.php http://lists.transmedia.de/mailman/listinfo/eci-en http://www.eci.org/eci/en/070_links.php _______________________________________________ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
