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

Reply via email to