On 07/22/2009 11:59 PM, Martin Cracauer wrote:

Hi.

Can somebody tell me how far away GIMP is from being able to view manipulations that you do in a different color space in real time in real colors?

Hi,

The current plan is get GIMP 2.8 out the door asap, hopefully within the next few months. Once that is done we will finish porting GIMP to GEGL. That means finally getting rid of all 8bpc-only code and introduce the GEGL data types. With the help of the babl library, GEGL can transparently process image data in any color space, including CIE Lab. See http://www.gegl.org/babl/BablFishPath.html for a more complete list.

Currently, neither babl nor GEGL is aware of ICC color profiles, but I don't expect it to be too much work to make GEGL color-profile aware. It is just a matter of feeding the right data into GEGL, which for the vast majority of operations works in linear light RGBA float.

So, once we have GEGL in place, working in any color space that has a one-to-one mapping to and from linear light RGBA (this does not include CMYK), should be fairly trivial.

/ Martin

On 07/23/2009 12:27 AM, Martin Cracauer wrote:

Do I understand that correctly that you will move to single-floats/color?

Yes, virtually all image processing and compositing will be performed in the linear light RGBA color space with 32 bit float depth per channel. There have been discussions about introducing regression tested optimizations for 8 and 16 bit depths, but I don't expect any effort to be put into that soon. First, we need to finalize getting GEGL into GIMP.

What exactly happens when you select the "use GEGL" menu item right now? It uses GEGL but only with the current capabilities? Does it give more than 8 bits/pixel?

If you in GIMP 2.6 enable Colors -> Use GEGL, then the image processing itself will occur in RGBA float for the color tools. However, the data being processed is stored as RGBA u8. That means that if you do an color adjustment with Use GEGL enabled, then you first have to convert that data to RGBA float for processing, and than back to RGBA u8 to store it again. In other words, not very useful to the end user.

If you in the yet not officially released GIMP 2.7 do View -> Use GEGL, then the layers will be composited using GEGL. In other words, we have the layers etc ported to a GEGL graph. It is worth mentioning that it is technically trivial to insert non-destructive nodes in the graph, but our focus now is getting GIMP 2.8 out.

/ Martin

On 07/23/2009 04:11 AM, Martin Cracauer wrote:

I use the git version of last week. Lost my tablet (probably due to some dbus API issue) but works otherwise.

Let me just poke some more.

And does all this survive layer copying and other changes?

Does current 2.7 carry floating point layers through all of this?

Does 2.7 as is support storing and reloading the floating point format in *.xcf files?

No, in git master, everything feeded to a GEGL graph is RGBA u8, and everything returned is RGBA u8, it is just the intermediate processing that is done in RGBA float. Part of the remedy for this is replacing GIMP's TileManager with GEGL's GeglBuffer, which can store image data in any format supported by babl.

/ Martin

On Thu, Jul 23, 2009 at 11:41 AM, Martin Cracauer wrote:

Martin Nordholts wrote on Thu, Jul 23, 2009 at 12:40:06AM +0200:

On 07/23/2009 12:27 AM, Martin Cracauer wrote:

Do I understand that correctly that you will move to single-floats/color?

[...]

If you in the yet not officially released GIMP 2.7 do View -> Use GEGL, then the layers will be composited using GEGL. In other words, we have the layers etc ported to a GEGL graph. It is worth mentioning that it is technically trivial to insert non-destructive nodes in the graph, but our focus now is getting GIMP 2.8 out.

I use the git version of last week. Lost my tablet (probably due to some dbus API issue) but works otherwise.

Let me just poke some more.

And does all this survive layer copying and other changes?

GEGL graphs are completely non-destructive (of course, you can flatten part or all of a graph to destroy information at any time.) The plan for GIMP here is that it will only modify the graph in the course of usual operations, which will enable the option of fully non-destructive workflow.
In this system, we simply have to decide the way to present this ability to insert arbitrary nodes at arbitrary positions to the user. The idea I regard as most sensible here is simply treating nodes like a container -- that is, the input being made up of 1 or more node outputs composited together. With this idea, you would be attaching an effect to a group of layers (and effects

There are issues with the above (primarily, I oversimplified -- we need to deal with nodes that simply produce, like eg. checkerboard, constant color, as well as filtering nodes), but that's a reasonable overall way to think about it for now.
IMO GIMP is heading towards providing a fairly thin abstraction layer over the abilities of GEGL graphs, which in general is good news for anyone concerned about possible leaky abstraction ("does all this survive layer copying and other changes") -- thick abstraction layers tend to be much leakier (for example, Photoshop's "Adjustment Layers" idea -- they are only layers in an absurdly broad sense (so broad as to be nearly meaningless), so they tend to disobey common-sense rules followed by other types of layer.)

In short:

the capacity for inserting arbitrary nodes is available in GEGL, but GIMP does not currently adulterate the constructed layer graph in any way; When some ability to control the graph in a finer way (like I described) is implemented, we ought to have moved on to the next-generation file format, which should support it in a straightforward way

Even shorter: A completely theoretical yes, since such functionality is currently available in GEGL, not leveraged by GIMP or presented to the user yet.

Let's use an example: I like to use the levels tools with a non-destructive adjustment first and although 2.6/2.7 allow me to take the levels I found right to curves I usually don't do this. I prefer to commit the level change, then duplicate the layer and mess with the curves in the new layer. This, of course, causes me losses from interpolation with the 8-bit channels, where it would not if I would edit levels and curves in the same moment without committing levels first and start over with curves. Does current 2.7 carry floating point layers through all of this?

There are no floating point layers yet. During the composition, the layer pixels are automatically converted to floating point, and converted back after composition. to display the finished projection. Thus, the difference in the resulting image is minimal.

During the application of a color tool, a similar thing happens: pixels are converted to float, the change is applied, and pixels are converted back. Eventually, using a color tool will just modify the image graph rather than directly writing pixels; at this time, floating point values will be preserved through that operation (and presumably most subsequently operations -- obviously if there is an explicit 'convert to 8bit' operation in use, floating point values are not going to last beyond that.

I just tried this and I get the same teeth in the histogram in 2.7 no matter whether I asked it to use GEGL or not, but I'm not sure I activate it the right way. This was just on a layer originating from a JPEG.

Does 2.7 as is support storing and reloading the floating point format in *.xcf files?

Again, floating point currently has nothing to do with the normal representation of image in the GIMP, yet. This should answer your question.
I believe we are planning to move to a new native image format for 3.0, which will address such problems as: metadata support being bolted on rather than a standard part of the file format, more sophisticated ICC support, support of higher bitdepths, support of different color models (LAB, YCbCr etc)...

David