Re: How far away from watching other colorspaces in real time?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





On Thu, Jul 23, 2009 at 11:41 AM, Martin Cracauer <cracauer@xxxxxxxx> 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
_______________________________________________
Gimp-developer mailing list
Gimp-developer@xxxxxxxxxxxxxxxxxxxxxx
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

[Index of Archives]     [Video For Linux]     [Photo]     [Yosemite News]     [gtk]     [GIMP for Windows]     [KDE]     [GEGL]     [Gimp's Home]     [Gimp on GUI]     [Gimp on Windows]     [Steve's Art]

  Powered by Linux