When Gegl?
This discussion is connected to the gimp-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.
| When Gegl? | Patrick McFarland | 21 Jul 21:42 |
| When Gegl? | Adam D. Moss | 21 Jul 21:47 |
| When Gegl? | Joao S. O. Bueno | 22 Jul 03:55 |
| When Gegl? | Patrick McFarland | 22 Jul 07:49 |
| When Gegl? | David Neary | 21 Jul 22:52 |
When Gegl?
So, if gegl isnt going to be in gimp2, when will it be?
Ive been waiting for gimp2 awhile now, and now that gegl wont be in it, I have to keep waiting. How long will I have to wait now? 2.2? 2.4?
When Gegl?
Patrick McFarland wrote:
So, if gegl isnt going to be in gimp2, when will it be?
Ive been waiting for gimp2 awhile now, and now that gegl wont be in it, I have to keep waiting. How long will I have to wait now? 2.2? 2.4?
gegl isn't a panacea...
When Gegl?
Patrick McFarland wrote:
So, if gegl isnt going to be in gimp2, when will it be?
Ive been waiting for gimp2 awhile now, and now that gegl wont be in it, I have to keep waiting. How long will I have to wait now? 2.2? 2.4?
I believe that the general idea (one with which I agree) is to have a quick 2.2 with some very small features going in. That should be out by Christmas. Then gegl would go in in the new year, and work would begin on gettiong gegl to the point where it replaces at least the current gimp functionality. There will also be floating point support from the start.
After that, we will need a tile iterator, a pixel accessor, more operations, and more colourspace definitions. We'll also need to redo a large part of the core (notably the channels stuff, and all the plug-ins) to take account of the generalised image structure. We will also need a new file format, IMHO. But that's being discussed elsewhere. A pity that people are more worried about whether jar or ar will be used to bunch layers together than they are about how the future gimp will handle layer trees and groups, adjustment layers, vector and text layers and all the other interesting difficult stuff, though.
Cheers, Dave.
PS. Excuse my tone. I've become a little bitter & twisted. I'm sure Berlin will fix that.
When Gegl?
On Monday 21 July 2003 4:47 pm, Adam D. Moss wrote:
Patrick McFarland wrote:
So, if gegl isnt going to be in gimp2, when will it be?
Ive been waiting for gimp2 awhile now, and now that gegl wont be in it, I have to keep waiting. How long will I have to wait now? 2.2? 2.4?
gegl isn't a panacea...
Perfectly said.
Actually, I've skimmed trhough some docs on the GEGL, and I wonder, what are its actual uses for the final user? I can see it provides the grounds for easier hacking in the GIMP, and will facilitate the implemanetation of internal CMYK and FLoating point images, and such. But for GEGL alone, what does the artist takes?
I can also see that it could be a nice engine to provide a customizable brush, or layer combine mode. I am writing such a resource for gimp 1.3, whithout GEGL, and even if it doesn't make it in the official tree, it will be avaliable to whoever wants to try it.
Of course, I am probably missing a lot of uses of the GEGLL - but I am gneuinely interested in knowing more about it.
Thanks,
JS ->
When Gegl?
On 21-Jul-2003, Joao S. O. Bueno wrote:
On Monday 21 July 2003 4:47 pm, Adam D. Moss wrote:
Patrick McFarland wrote:
So, if gegl isnt going to be in gimp2, when will it be?
Ive been waiting for gimp2 awhile now, and now that gegl wont be in it, I have to keep waiting. How long will I have to wait now? 2.2? 2.4?
gegl isn't a panacea...
Perfectly said.
Actually, I've skimmed trhough some docs on the GEGL, and I wonder, what are its actual uses for the final user? I can see it provides the grounds for easier hacking in the GIMP, and will facilitate the implemanetation of internal CMYK and FLoating point images, and such. But for GEGL alone, what does the artist takes?
Ive been having a long discussion with Robin Rowe about stuff he possibly wants to do with CinePaint. I am, in this context, an artist.
Stuff like CMYK is obvious how thats useful. (Desktop -> printer stuff, etc)
Floating point, however, is harder to wrap your mind around. The short answer is that quantiziation of data is bad, and more precision is better.
To continue on this line of thinking, integers are limited to 0.0 and 1.0 (In 8bit per channel images, this is 0 through 255). Once its goes above 1.0, or below 0.0, data is lost. Floating point values are not clipped, so data is not lost.
In addition, gegl would have been able to internally calculate using higher precision values, which allows it to unresrect itself from the "accumulating error." (Basic programming concept, google for it.) So, you may have 8 bits per channel, but over the course of a dozen layers, you have tons of data. (More than can be represented in 8 bits at all times.)
To avoid the accumulating error from snowballing, you use a much higher precision to calculate it. Floating point math comes in handy here too.
So, with floating point, we've avoided clipping, and we've avoided premature quantization and accumulating of errors.
Of course, most of what I said above applies to what you call "layer combining." To apply floating point goodness to individual layers, take the common arguments for 8 bit per channel vs 16 bit per channel, and replace 8 bit with the word "integer", and 16 bit with the phrase "floating point". _In addition_ to the higher precision (called a larger dynamic range in film talk), you also can ignore clipping, because floating point doesnt have it.
As an artist, the high precision layer combining is a godsend, and as a very gimp-abusive artist, high precision and no clipping all around is a godsend.
So, this is why Im disapointed that it never came into being.
