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@xxxxxxxxxxxxxxxxxxxxxx
> http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
>
--
Hal V. Engel
Attachment:
pgpcTM6eNFFAA.pgp
Description: PGP signature
