RSS/Atom feed Twitter
Site is read-only, email is disabled

GEGL development/gimp integration

This discussion is connected to the gegl-developer-list.gnome.org mailing list which is provided by the GIMP developers and not related to gimpusers.com.

This is a read-only list on gimpusers.com so this discussion thread is read-only, too.

7 of 7 messages available
Toggle history

Please log in to manage your subscriptions.

GEGL development/gimp integration Øyvind Kolås 31 Dec 20:42
  GEGL development/gimp integration Hal V. Engel 01 Jan 22:42
GEGL development/gimp integration Øyvind Kolås 02 Jan 01:10
GEGL development/gimp integration Sven Neumann 02 Jan 03:39
  GEGL development/gimp integration Hal V. Engel 03 Jan 23:18
GEGL development/gimp integration Sven Neumann 03 Jan 23:27
GEGL development/gimp integration Dave Neary 04 Jan 13:52
Øyvind Kolås
2004-12-31 20:42:13 UTC (about 19 years ago)

GEGL development/gimp integration

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.

Hal V. Engel
2005-01-01 22:42:44 UTC (about 19 years ago)

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
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.

Øyvind Kolås
2005-01-02 01:10:52 UTC (about 19 years ago)

GEGL development/gimp integration

On Sat, 1 Jan 2005 13:42:44 -0800, Hal V. Engel 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.

Sven Neumann
2005-01-02 03:39:04 UTC (about 19 years ago)

GEGL development/gimp integration

Hi,

"Hal V. Engel" 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

Hal V. Engel
2005-01-03 23:18:03 UTC (about 19 years ago)

GEGL development/gimp integration

On Saturday 01 January 2005 18:39, Sven Neumann 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.

Sven Neumann
2005-01-03 23:27:19 UTC (about 19 years ago)

GEGL development/gimp integration

Hi,

"Hal V. Engel" 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

Dave Neary
2005-01-04 13:52:10 UTC (about 19 years ago)

GEGL development/gimp integration

Hi Sven,

Selon Sven Neumann :

"Hal V. Engel" 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