The general and good advice is to not use Gimp 2.9 for "production" work. But I've been using Gimp 2.9 for everything I do with Gimp these days and so far it's been rock solid (albeit very slow on large images). I quite like the new Gimp and I've finally gotten used to using "Save" and "Export".

I took a break from working on the lcms2 plugin to write an article on gamma artifacts from mixing colors (gaussian blur, Normal mode blending) in a nonlinear RGB color space. I used Gimp 2.9 (last compiled July 25, 2012, and using my lcms2 plugin) for all of the image blurring and blending. If anyone is interested, the article is here:
Linear Gamma vs Higher Gamma RGB Color Spaces: Gaussian Blur and Normal Blend Mode
http://ninedegreesbelow.com/photography/linear-gamma-blur-normal-blend.html

While working on the article, I noticed that the Gimp Gegl gaussian blur nicely blurs *regular* sRGB images without the darkening artifacts that normally accompany gaussian blurring. But when used on a linear gamma image, the Gegl gaussian blur makes it look like the image was actually blurred in a gamma=0.45 color space (there are "lightening" artifacts). So similar to the problem when opening a 16-bit tif, there seems to be a strange gamma error involved.

The regular Gimp 2.9 gaussian blur works exactly as it is supposed to do on both linear and regular sRGB, that is, there are darkening artifacts in the regular sRGB color space, but not in the linear sRGB color space.

I put up some sample images showing the Gimp Gegl gaussian blur vs regular blur: Gimp 2.9 Gegl and regular gaussian blur http://ninedegreesbelow.com/temp/gimp29-gegl-blur.html

Also, it seems the Gegl gaussian blur "Size" is different from regular gaussian blur "pixel": Size 10 seems to be approximately 30 pixels, which will take some getting used to. I didn't check to see if the Size/pixel ratio seems constant across different sizes. Does anyone know if it is?

Elle Stone

On 8/5/12, yvind Kols wrote:

On Sat, Aug 4, 2012 at 11:44 PM, Elle Stone wrote:

While working on the article, I noticed that the Gimp Gegl gaussian blur nicely blurs *regular* sRGB images without the darkening artifacts that normally accompany gaussian blurring. But when used on a linear gamma image, the Gegl gaussian blur makes it look like the image was actually blurred in a gamma=0.45 color space (there are "lightening" artifacts). So similar to the problem when opening a 16-bit tif, there seems to be a strange gamma error involved.

How do you create a linear gamma image to do your tests? The only way you actually can do that is to open a PNG image that is 16 bit (or to create a 16bit / 32bit image in the first place).

The way I created the linear gamma sRGB test images was as follows: *Create an image of the appropriate size with Gimp. *Set the precision to 16 bits.
*Assign the profile I wanted to use, which was a linear gamma version of sRGB. *Create the test image.
*Export as a 16-bit png.

The first test image I created was composed of color blocks, all of which had R, G, and B values of either 255 or 0 (that is, 100% saturated, 100% bright magenta, yellow, teal, green, blue, and red, plus black and white).

If you take a gamma
encoded image and change it's profile to be "linear light" with lcms you are changing the pixel values of the image,

Terminology can be confusing. Just to make sure we are talking about the same thing, to me, "linear light" refers to a rather odd blend mode. But I'm pretty sure that you use the phrase to mean any RGB profile with a linear gamma tone response curve, or perhaps you mean specifically a linear gamma version of sRGB.

By "change" do you mean "convert to" or "apply/assign" an ICC profile? Regardless, as long as the primaries are still the sRGB primaries, if all the R, G, and B values are either 255 or 0 (as in my first test image), starting with a linear gamma sRGB profile and either *applying* a regular sRGB profile or *converting* to a regular sRGB profile, produces an image in which none of the image R, G, and B values have changed.

Otherwise, if any of the RGB values are not either 255 or 0, then of course the RGB values change when you *convert* from linear gamma sRGB to regular sRGB. And *applying* keeps the values the same but changes the "meaning" of the RGB values.

but the meta data
passed around in terms of bablformats in the GeglBuffer will still state that this is sRGB data, and when gegl:gaussian-blur is blurring it that sRGB data will be converted to linear light data for the actual blurring.

Are you saying is that babl/gegl always acts as if any image opened by Gimp is really in the regular sRGB color space, with sRGB's peculiar "almost gamma=2.2" tone response curve? Or that if the image is created by Gimp, even after a diffferent ICC profile is assigned, that babl/gegl still assumes that the image is an sRGB image, with the peculiar sRGB tone response curve?

What I would have assumed would happen, is that "behind the scenes" gegl/babl creates (something like a) linear scRGB version of the image (by literally converting the image *from* whatever RGB color space it happens to be in *to* the scRGB color space) and then applies the gegl/babl gaussian blur to the *converted* image (not to the original image).

If what I just described is what really happened, then there would be no gamma error during the gegl gaussian blur. The linear gamma image would be converted to linear scRGB "behind the scenes", blurred correctly, and converted back to the original linear gamma profile upon exporting the image. And the regular gamma image would be converted to linear scRGB "behind the scenes", blurred correctly, and converted back to the original regular gamma profile upon exporting the image.

But what really seems to be happening is that gegl/babl assumes all images have the sRGB not-quite-gamma-2.2 tone response curve, regardless of the image profile's actual tone response curve. In other words, there doesn't seem to be any "behind the scenes" converting *from* the ICC profile the image has upon opening, *to* the babl/gegl internal working space, before the gegl operation is applied to the image.

For newly created images in GIMP-2.9 the buffers are created as sRGB (gamma encoded), since this is where gamma encoding makes sense; giving higher fidelity in the shadows. For higher bitdepths GIMP-2.9 creates linear light buffers.

Elle

gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Some day I might figure out how to use email. In the meantime, here's the rest of what should have been part of the previous email:

but the meta data
passed around in terms of bablformats in the GeglBuffer will still state that this is sRGB data, and when gegl:gaussian-blur is blurring it that sRGB data will be converted to linear light data for the actual blurring.

Are you saying is that babl/gegl always acts as if any image opened by Gimp is really in the regular sRGB color space, with sRGB's peculiar "almost gamma=2.2" tone response curve? Or that if the image is created by Gimp, even after a diffferent ICC profile is assigned, that babl/gegl still assumes that the image is an sRGB image, with the peculiar sRGB tone response curve?

What I would have assumed would happen, is that "behind the scenes" gegl/babl creates (something like a) linear scRGB version of the image (by literally converting the image *from* whatever RGB color space it happens to be in *to* the scRGB color space) and then applies the gegl/babl gaussian blur to the *converted* image (not to the original image).

If what I just described is what really happened, then there would be no gamma error during the gegl gaussian blur. The linear gamma image would be converted to linear scRGB "behind the scenes", blurred correctly, and converted back to the original linear gamma profile upon exporting the image. And the regular gamma image would be converted to linear scRGB "behind the scenes", blurred correctly, and converted back to the original regular gamma profile upon exporting the image.

But what really seems to be happening is that gegl/babl assumes all images have the sRGB not-quite-gamma-2.2 tone response curve, regardless of the image profile's actual tone response curve. In other words, there doesn't seem to be any "behind the scenes" converting *from* the ICC profile the image has upon opening, *to* the babl/gegl internal working space, before the gegl operation is applied to the image.

On 8/5/12, yvind Kols wrote:

GIMP-2.9 is only partially on it's way through to be fully working properly with GEGL/babl. ICC profiles should only need to be involved upon loading files from disk and exporting to files used outside - internally it is up to GIMP/GEGL/babl to assign appropriate fully color managed color spaces to the raster storage of the buffers in the layers; for 8bpc precision this will be sRGB and for higher bitdepths this should be linear light/linear scRGB. GEGL through babl knows how to _accurately_ and efficiently convert between the color spaces and representations native to babl (without interpolated lookup tables),

this differs from any assumptions that might have been in 2.8 and before wrt color management and the ability to assign color profiles to images; I would not trust (and want GIMP to get rid of) any such things in the UI.

I don't think I understand what the preceeding sentence says. I think it says that ultimately, when all changeover to gegl/babl is complete, Gimp should *not* allow the user the option of assigning one or another ICC color space profile to an image, and *not* allow the user to convert an image from one ICC profile to another. But that can't be right, can it?

PS: I try to make sure that babl and GEGL do what they promise; this is already more than I have time or energy to deal with; thus I try stay out of GIMP unless it is changes I have made to GEGL that directly stops GIMP from building.)

My apologies - where Gimp leaves off and gegl/babl take over is not something that I thought about, and I'm still working on figuring out what (and who!) does what.

I was hoping (wishful thinking?) that maybe the same 0.45 gamma error that makes tif thumbnails look correct and png thumbnails incorrect (too dark), whereas 16-bit tifs load incorrectly (too light), and pngs load correctly, might also be related to the gegl incorrect blurring of a linear gamma image, as if it had a gamma of 0.45 instead of 1, plus the Gimp 2.8 gamma error of 0.45 reported in this thread: https://mail.gnome.org/archives/gimp-developer-list/2012-July/msg00050.html

gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

On 8/7/12, yvind Kols wrote:

On Mon, Aug 6, 2012 at 7:35 PM, Elle Stone wrote:

On 8/5/12, yvind Kols wrote:
I don't think I understand what the preceeding sentence says. I think it says that ultimately, when all changeover to gegl/babl is complete, Gimp should *not* allow the user the option of assigning one or another ICC color space profile to an image, and *not* allow the user to convert an image from one ICC profile to another. But that can't be right, can it?

I'll try to explain the desired situation in the end differently:

Files coming into GIMP and going out of GIMP might have assigned ICC profiles, this is for import and export.

There should be ways to change the colors in a buffer to correct for a wrong profile. As well as deciding that you want to export images from the composition with a different profile from the input.

Having thought about it, the only situation I can think of where what you describe might possibly present a problem is when opening an interpolated raw file that was saved as "raw color" and hence doesn't have an embedded profile, or where the embedded profile is a camera profile, and perhaps the person wants to apply several other camera profiles in turn, before deciding which one to use.

Among people who profile their own camera, choosing which of several camera profiles to use with a given interpolated-but-still-raw-color image is not uncommon, which means applying each profile in turn before deciding which one to use.

Also consider if the person is testing a new profiling procedure, or in the process of creating a new camera profile (conceptually distinguishable, even if the same steps get used). In either case, one might want to "apply, export, apply, export, etc" for further comparisons of the resulting colors/tonality.

Does the envisioned way Gimp should eventually work compatible with applying several camera profiles before deciding which one to use? And/or with "apply/export/apply new/export/etc" when testing camera profiles?

Elle

gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

On 8/8/12, Michael Natterer wrote:

By discussing here, you turned yourself into a contributor to the definition of that future workflow and feature set. Since you know quite a lot and have an opinion, why not suggest how it *should* work, in your opinion, along the constraints that the conversions will only ever happen upon import and export (plus the possibility to convert a buffer in order to correct wrong profiles).

At first the idea of doing away with assigning and converting except on import and export seemed a bit extreme (translation: not what I'm used to!). However, after thinking about it, the only case I could think of where it might cause a problem was as I described, when wanting to try several profiles before choosing one profile to apply to the raw color image. Or when profile testing.

How it should work would be as described, that during image import, Gimp would provide the option of "trial assigning" more than one profile to the image. The image might or might not have an embedded camera profile. If it does, then Gimp will probably ask "should it be converted . . ." and the answer would of course be "no, keep the existing . . ." But then in fact the next step would be to start assigning alternative profiles. (Perhaps a check box: profile testing?)

This same procedure - the ability to "test assign" multiple profiles - would also be of use when importing an image when you don't really know what profile the image ought to have, either because either the wrong profile was embedded (it does happen!) or because there is no embedded profile.

Although cases of missing/wrong profiles are probably somewhat common, I will guess that most people will likely not ever bring a raw color image into Gimp in the manner I described, as most people likely use their raw processing program to apply the camera profile and then convert to a standard working space.

So if what I described above isn't super easy to accomodate (or already planned as possible), then personally I don't think it's worth worrying about. To put into context, if I had to choose between easy profile assigning/testing and easy soft proofing, I would take easy soft proofing any day of the week:

Soft proofing is something I want to do with any image that I really care about. Camera profile testing is something I do only occasionally. And I only remember one time needing to guess which profile an image ought to have, though some people probably encounter this issue more often, depending on how images arrive in their digital darkroom.

Kindest regards,
Elle