I remember the color management work flow being talked about on this 
list in the past.  I think there are still some misconceptions about 
how this should work.  I see that ěyvind shows a work flow that 
converts from the images input color space to some apparently 
arbitrary color space (rgb8) when the image is loaded and then 
converted back to the input color space when the image is saved.  That 
means that every time the image is opened and saved it will go through 
two color space transformations.  My experience is that other tools 
such a Photoshop do not do this and I believe that this is a flawed 
design.  The image should always remain in its original color space 
unless the user has requested that the image be converted to a new 
color space (from an input device space to a working space for 
example).  So the correct flow would look like this.

1) loading the image
    
 .-----------------------.  .---.
 |load_tif               |    |foo|
 |  resource = "in.tif"  => gimp drawable ('CMYK')
 `-----------------------' `---'
 
 2) saving the image
 
                .---.    .---------------------.
                |bar|   |save_tif             |
   gimpdrawable-=> resource='out.tif' |
               `---'   `-----------------------' 
 
 3) displaying the image
 
                   .---.   .-----------------------.   .---.
                   |bar|   |lcms                   |   |foo| 
 gimp drawable -=> |   |-->|  in_profile='CMYK'    |-->|   | -=> gimp 
drawable
                   |   |   |  out_profile='crt.icc'|   |   |
                   `---'   `-----------------------'   `---'


There is simply no reason for the extra color space conversions and 
there are many reasons not to do it.  Specifically the repeated 
conversions as the image is opened and saved would introduce changes 
to the color space of the image that would result in increased color 
errors as the image was worked on over time. 

Once an image is in the working color space it should remain in that 
space.  The only time a color space conversion should happen after 
that is when the image is being sent to another device such as the 
display or a printer.  Even then the image itself is not converted but 
rather a temporary copy is converted and sent to the device.  
 



On Friday 31 December 2004 11:42, ěyvind Kolňs wrote:
> After some discussions it seems that using GEGL for display filters,.
> and other color management issues involving lcms might be a good 
idea.
> Does the people with code checked into GEGL have any opinon on this
> approach?
> 
> /ěyvind K.
> 
> ---
> Ramblings follow:
> 
> We will work on a sample color image, called in.tif, the color 
management
> directly touching the image are the following operations:
> 
> 1) loading the image
> 2) displaying the image
> 3) saving/exporting image
> 
> lcms should be used for the actual transformations,. some 
transformations we
> do manually, for instance conversion between guchar8, guint16 and 
gfloat.
> 
>                                      .----> lcms --->  display
>                                     /
>                                    /
> in.tif -> lcms -> gimp does foo --<
>                                    \
>                                     \
>                                      `----> lcms --->  out.tif
> 
> 
> 
> 
> The three operations again, as GEGL graphs, having the actual file
> savers/loaders
> and the lcms operation as GEGL ops.
> 
> 1) loading the image
>    
> .-----------------------.   .---------------------.   .---.
> |load_tif               |   |lcms                 |   |foo|
> |  resource = "in.tif"  |-->|  in_profile='CMYK'  |-->|   | -=> gimp 
drawable
> |                       |   |  out_profile='rgb8' |   |   |
> `-----------------------'   `---------------------'   `---'
> 
> 2) saving the image
> 
>                .---.   .-----------------------.   .---------------------.
>                |bar|   |lcms                   |   |save_tif             
|
> gimpdrawable-=>|   |-->|  in_profile='rgb8'    |-->|  
resource='out.tif' |
>                |   |   |  out_profile='cieLAB' |   |                     
|
>                `---'   `-----------------------'   
`---------------------'
> 
> 3) displaying the image
> 
>                   .---.   .-----------------------.   .---.
>                   |bar|   |lcms                   |   |foo| 
> gimp drawable -=> |   |-->|  in_profile='rgb8'    |-->|   | -=> gimp 
drawable
>                   |   |   |  out_profile='crt.icc'|   |   |
>                   `---'   `-----------------------'   `---'
> 
> 
> bar is to transform from gimps image representation to GEGLs, and foo
> is the opposite.
> 
> 
> Choosing a gimp image representation to work with:
> ==================================================
> 
> To ease the process, using an as simple as possible gimp image
> representation as the inputs
> and outputs of foo and bar would be needed, using tiles directly,
> means we deal with a linear
> buffer. This will cause som extra code in gimp, but it means we can
> happily coexist with
> exsisting tile based code. This only works well for point operations,
> and not for area
> operations like blur. Thus:
> 
> gimptile_read
> 
> and
> 
> gimptile_write
> 
> are would be the initial point of contact between gimp and gegl.
> 
> Special code to apply a processing graph to all tiles in an image
> would be needed then,
> a convenience function should be made. An ideal property interface to
> lcms needs to be
> found.
> 
> 
> 
> 
> -- 
> Software patents hinder progress | http://swpat.ffii.org/ 
> Web :  http://pippin.gimp.org/
> _______________________________________________
> Gimp-developer mailing list
> Gimp-developer@lists.xcf.berkeley.edu
> http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
> 

-- 
Hal V. Engel

Attachment: pgpi6OSIi4ofD.pgp
Description: PGP signature

Reply via email to