Re: [Gegl-developer] Re: [Gimp-developer] GEGL development/gimp integration
Hi Sven, Selon Sven Neumann [EMAIL PROTECTED]: Hal V. Engel [EMAIL PROTECTED] writes: it appeared to me that this approach had been rejected, or at least discredited, at that time. At the very least there were sound reasons put forward that called this approach into question and the only arguments on the other side were that it made programming the color management stuff a little easier. But I am also aware that there were many involved in the earlier thread on this subject that did not seem to think there was an issue with this approach. I don't think we rejected this part. IIRC we said that it should be optional and that we want to allow people to disable color management entirely. Anyway, whatever we decide to do is just a matter of user interface and doesn't affect the GEGL operators involved. The short summary of the entire discussion is something like this: We should allow a colour profile to be associated with an image if possible, and only apply it (that is, change the colorspace of an image) if explicitly requested. There will be issues with things which aren't colorspace dependent (like the color picker) as well as copying and pasting between images, which will cause problems, but for the moment the damage caused by these would be less than applying color profiles on load. However, we should have a default working colourspace, and the user should be able to convert to that colourspace on load. This should be configurable. There should also be an option to disable colour management altogether - in which case, we work in the default colourspace, don't do any conversion at all, and simply load and save the colour profile as a parasite attached to the image. My understanding was that the solution which Alastair Robinson was working on was to have a plug-in to apply a color profile, but also to have the idea of a (per-image) working colourspace, and a configurable (global) display colour profile and default working colourspace. That is, every image loaded which doesn't have an attached profile will be assumed to be in that default colourspace. If it has an attached profile, the user will be offered the choice of (1) applying the profile to get to the default colorspace, (2) working in the embedded profile's colorspace or (3) disabling color management for the image, in which case we work in the default colorspace, but don't apply the profile. Again, this is a synthesis of my understanding of that discussion, the archives are the best reference for what was said, though. Cheers, Dave. -- Dave Neary Lyon, France ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GEGL development/gimp integration
On Saturday 01 January 2005 18:39, Sven Neumann [EMAIL PROTECTED] writes: Hi, snip Did you read the earlier discussions on this topic? If not, I suggest that you do that now. Sven Sven, Yes I did read the earlier discussion several times but that was a few months ago. That is why I was surprised that a proposal surfaced here that involved doing color transformations as part of loading and saving images. This was a major part of the earlier discussions and it appeared to me that this approach had been rejected, or at least discredited, at that time. At the very least there were sound reasons put forward that called this approach into question and the only arguments on the other side were that it made programming the color management stuff a little easier. But I am also aware that there were many involved in the earlier thread on this subject that did not seem to think there was an issue with this approach. Perhaps I misinterpreted the earlier discussion and the approach was accepted or perhaps no concensus was reached. Which leaves me in what is probably a confused state of mind on this. So at this point I do not know if a consensus was reached earlier and if so what it was. I think I should point out that color management in GIMP is a major point of interest for me as it is the only thing at this point in time that keeps me from using The GIMP. I have been using a full, end to end, color managed work flow in my digital dark room for some time now and I consider it to be an essential element. So I have been following this in some detail for a while. I subscribed to this list specificly so that I could track progress on the color management sub-system and to perhaps participate in the discussion if it appeared that I had something to offer. When I saw the same flawed assumptions as in the earlier discussion I thought that I should point out the flaw now rather then wait. After all it is much easier and less costly to fix a design flaw early in the process than it is later on. -- Hal V. Engel pgpuLyLVpil4i.pgp Description: PGP signature
Re: [Gimp-developer] GEGL development/gimp integration
Hi, Hal V. Engel [EMAIL PROTECTED] writes: Yes I did read the earlier discussion several times but that was a few months ago. That is why I was surprised that a proposal surfaced here that involved doing color transformations as part of loading and saving images. This was a major part of the earlier discussions and it appeared to me that this approach had been rejected, or at least discredited, at that time. At the very least there were sound reasons put forward that called this approach into question and the only arguments on the other side were that it made programming the color management stuff a little easier. But I am also aware that there were many involved in the earlier thread on this subject that did not seem to think there was an issue with this approach. I don't think we rejected this part. IIRC we said that it should be optional and that we want to allow people to disable color management entirely. Anyway, whatever we decide to do is just a matter of user interface and doesn't affect the GEGL operators involved. I think I should point out that color management in GIMP is a major point of interest for me as it is the only thing at this point in time that keeps me from using The GIMP. I have been using a full, end to end, color managed work flow in my digital dark room for some time now and I consider it to be an essential element. So I have been following this in some detail for a while. I subscribed to this list specificly so that I could track progress on the color management sub-system and to perhaps participate in the discussion if it appeared that I had something to offer. When I saw the same flawed assumptions as in the earlier discussion I thought that I should point out the flaw now rather then wait. After all it is much easier and less costly to fix a design flaw early in the process than it is later on. Sure, that's much appreciated. Perhaps you want to suggest a better design then? Sven ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GEGL development/gimp integration
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
Re: [Gimp-developer] GEGL development/gimp integration
On Sat, 1 Jan 2005 13:42:44 -0800, Hal V. Engel [EMAIL PROTECTED] wrote: 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. 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. NB: This document outlined a potential starting point for integrating GIMP with GEGL, not a definite guide to the ideal color management over time. When editing multiple times, gimp should prefer to save the image with a profile to its internal working samplemodel and colorspace, thus making both load and save conversions passthrough filters on repeated edits. /Øyvind K. -- 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
Re: [Gimp-developer] GEGL development/gimp integration
Hi, Hal V. Engel [EMAIL PROTECTED] writes: 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. Did you read the earlier discussions on this topic? If not, I suggest that you do that now. Sven ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
