See http://www.gegl.org/

On Monday 31 October 2005 12:42 pm, Brannon King wrote:

It was my plan to write some beautiful DFT and Wavelet filters for GIMP, as I've done a fair amount of that for work lately. Then, to my great dismay, I realized today that there is no support for 12 or 16 bit channels. Alas, I don't think it's possible without that feature. I have some time that I could use to code 16bit channel support if someone could give me detailed instructions on the matter. I assume it's a fairly in-depth project, but I'm sure there is a fair number of requests for the feature as well.

On 10/31/05, Brannon King wrote:

So I was told to see the GEGL info.

That website (gegl.org) drastically needs a FAQ. Perhaps someone can answer these questions for me:

1. Is GEGL made to replace a certain core piece of GIMP or is it made to reroute data somehow? 2. Why is it not part of the GIMP core currently? 3. Is it activelly being worked on? Is its mailing list still used?
4. It appears to just be an API. Why would using this be better than changing the current GIMP core to support 16bit channels directly? Or are we planning to do just that and just use the GEGL API data structures and constructs?
5. How close is the GEGL code to usable? 6. Will it even work with the current GIMP codebase?

If memory serves me right, 8-bit support is pretty mostly hard-coded (or something akin to that) in the current GIMP base, unfortunately. Past talk of adding 16-bit support has sounded as though it requires a major revamping of even core underlying systems that comprise GIMP (sounds like a re-write, almost, even). GEGL (Generic Graphical Library) apparently has something to do with the new-fangled underlying framework for such a project. But I have no idea on the subject, I'm just trying to recall what others have said on this list from memory.

7. Has anyone worked on a merge plan for combining GEGL work with the current GIMP codebase?

I believe it's planned for some future release somewhere, but has been continually put off due to a lack of manpower. Or something of that sort. That said, I'm myself wondering whether a 16-bit capable gimp requires a fork, and if so, how much support that fork would get. Should you go forward with this (and I hope you do, as many have been asking for this), then I do wish you good luck, and hope that it comes out quite well.

Because I haven't been following development long enough (I'm afraid), someone else probably has a lot of details to add that I may have missed.

--
~Mike C
- Just my two cents
- No man is an island, and no man is unable.

On 10/31/05, Brannon King wrote:

That website (gegl.org) drastically needs a FAQ.

I'd also search the gimp-developer archives, there have been a lot of posts here about it.

1. Is GEGL made to replace a certain core piece of GIMP or is it made to reroute data somehow?

It's a general, and very ambitious, image processing library that is supposed to provide the core image handling system for the next GIMP. Progress stopped for a long time because of lack of personpower (perhaps a problem with an ambitious project), but I understand it's now being heavily worked on again.

4. It appears to just be an API. Why would using this be better than changing the current GIMP core to support 16bit channels directly? Or are we planning to do just that and just use the GEGL API data structures and constructs?

No, it's an implementation as well. Having a separate library is good for maintenance, and breaking the UI and the processing apart makes it possible to do fancier stuff, such as operation chaining and code generation, which will take GIMP some way beyond photoshop (at least in this respect).

(I'm not a gegl developer, just repeating what I've read here)

John

On 11/1/05, michael chang wrote:

On 10/31/05, Brannon King wrote:

So I was told to see the GEGL info.

That website (gegl.org) drastically needs a FAQ. Perhaps someone can answer these questions for me:

http://www.gegl.org/new/ was the state of the new GEGL web page a couple of years ago when GEGL had some momentum. I spent a large portion of this summer familiarizing myself with the GEGL code base with the intention to pick up the work again, but progress is a bit slow since I have quite a few other obligations as well. Gggl[1] is my prototype of a GEGL like library (the download able software is out of sync with my local tree at the moment and is unlikely to change in the immediate feature (before Christmas).

My GEGL focused energies were redirected to a helper library to do pixel representation conversions this summer, and I am trying to find the odd hour or two I can spare the project each month, babl[2] is currently in a usable state and needs some minor cleanups before an API frozen 1.0 release can be made.

1. Is GEGL made to replace a certain core piece of GIMP or is it made to reroute data somehow?

GEGL is intended to replace at least the compositing in the layers stack, but since it is a general graph based compositing architecture it is likely that all image processing functionality of the GIMP should be migrated to GEGL-nodes (including filters and tools).

2. Why is it not part of the GIMP core currently?

Because GEGL isn't able to process image data yet, thus The GIMP would be unusable if it should depend on GEGL in its current state.

3. Is it activelly being worked on? Is its mailing list still used?

http://cvs.gnome.org/viewcvs/*checkout*/gegl/ChangeLog http://cvs.gnome.org/viewcvs/*checkout*/babl/ChangeLog

4. It appears to just be an API. Why would using this be better than changing the current GIMP core to support 16bit channels directly? Or are we planning to do just that and just use the GEGL API data structures and constructs?

Cinepaint which used to be called FilmGimp which forked off the Gimp is going down this route.

5. How close is the GEGL code to usable?

Hard to say since there has been a discontinuity in the development (take a look at the ChangeLog and see which people have been active at what time.)

6. Will it even work with the current GIMP codebase? 7. Has anyone worked on a merge plan for combining GEGL work with the current GIMP codebase?

Much of the GIMP development over the last few years have been about modularizing and gobjectifying the code this has lead to a separation that will make a merge with GEGL easier in the future. At the moment I think the GIMP code base is in a phase where gradual replacement of the code with GEGL based bits could happen if GEGL was ready, but GEGL isn't ready.

/Øyvind K.

1 : http://pippin.gimp.org/gggl/ 2 : http://pippin.gimp.org/babl/
--
«The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/ http://ffii.org/

On 11/1/05, Øyvind Kolås wrote:

Much of the GIMP development over the last few years have been about modularizing and gobjectifying the code this has lead to a separation that will make a merge with GEGL easier in the future. At the moment I think the GIMP code base is in a phase where gradual replacement of the code with GEGL based bits could happen if GEGL was ready, but GEGL isn't ready.

Would it be a good idea to create a TODO list for GEGL, so that everyone interested could have a look and pick a task that he would be able to accomplish?

Like this:

1. Feature 1 - task 1
- task 2
- task n

2. Feature 2...

The fact is that nobody really knows about the true state of GEGL except very few people who contributed to it within last 2 years. Which is the source of confusions of all kinds a propos GEGL and its integration into GIMP.

It would be also good to automatically redirect people to the newer version of the website.

And the FAQ needs update:

1.6. Q: Is there a plan to use GEGL in GIMP? A: (paste your answer here)

This would also eliminate a lot of confusion and this particular task looks like a 5 minutes long work. Many people would appreciate this kind of attention (including myself :))

Alexandre

Alexandre Prokoudine wrote:

On 11/1/05, Øyvind Kolås wrote:

Much of the GIMP development over the last few years have been about modularizing and gobjectifying the code this has lead to a separation that will make a merge with GEGL easier in the future. At the moment I think the GIMP code base is in a phase where gradual replacement of the code with GEGL based bits could happen if GEGL was ready, but GEGL isn't ready.

Would it be a good idea to create a TODO list for GEGL, so that everyone interested could have a look and pick a task that he would be able to accomplish?

http://www.gegl.org/TODO.html seems to be something like that.

On 11/1/05, Alexandre Prokoudine wrote:

On 11/1/05, Øyvind Kolås wrote:
Would it be a good idea to create a TODO list for GEGL, so that everyone interested could have a look and pick a task that he would be able to accomplish?

If I am asked to create such a list right now it has a single item:

1) create a TODO list/roadmap

I have my own personal TODO list for GEGL it is as follows:

1) understand the existing code base 2) make it process images

Once GEGL is a working entity it will be easier to figure out what needs fixing and how. I thought that I might be able to achieve those goals this summer but understanding and adapting the architecture of a nonworking piece of software with the complexity and demands that GEGL is a large task and I failed. I got sidetracked the moment I found myself a TODO item (which is what turned into babl).

I have to prioritize my time and the GEGL task is currently swapped out of memory, to disk or maybe even to /dev/null. Right now the only free software projects that manages to get slices of my time is babl, since I am already using it for other purposes than GEGL.

I am hoping to have slightly more time available after new year and be able to pick up development again. If someone else has the time and energy needed to get GEGL going again it would be greatly appreciated by everyone and it would not be stepping on any ones toes.

/Øyvind K. --
«The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/ http://ffii.org/

On 11/1/05, Roel Schroeven wrote:

http://www.gegl.org/TODO.html seems to be something like that.

Yes, except it was updated on 12 February, 2003 :)

I'm not saying that somebody is obligated to do it, because as contributor I understand how difficult it can be to find even 5 minutes for a simple task. I just see the same situation over and over again, when people have no idea what is happening and where to begin from.

Three people or so claimed to be interested in helping out with GEGL at least since I'm reading this list (~1 year, and I'm sure there were more people) and they were most likely discouraged. Maybe it's time for them to talk? Oh well, this might be the wrong ML for such a topic. I'm sorry then.

Alexandre

On 11/1/05, Roel Schroeven wrote:

Alexandre Prokoudine wrote:

Would it be a good idea to create a TODO list for GEGL, so that everyone interested could have a look and pick a task that he would be able to accomplish?

http://www.gegl.org/TODO.html seems to be something like that.

That list of items might reflect things that needs to be done http://cvs.gnome.org/viewcvs/*checkout*/gegl/TODO (which contains notes I've almost forgotten were commited to CVS) might contain others.

/Øyvind K.

--
«The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/ http://ffii.org/

On 11/1/05, Brannon King wrote:

http://www.gegl.org/new/

Thanks for the link to the new website.

1 : http://pippin.gimp.org/gggl/
2 : http://pippin.gimp.org/babl/

So is it your opinion that we should ditch GEGL and use BABL instead since you think it is in a usable state?

Babl is a library to convert between different pixel representations (colorspaces and bitdepths). GEGL intends to be a complete image processing framework, that can do both compositing and filter effects (current Gimp plug-ins would probably have to be migrated to be GEGL Ops (plug-ins for GEGL) when they take the step up from 8bit).

Babl is in a usable state, but babl is a tiny component that is intended for integration into GEGL.

/Øyvind K.

-- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/ http://ffii.org/

Brannon King writes:
> compositing (I think that term refers to handling/merging the image > data formats)

Umm, no. As far as I know compositing refers to the handling/merging of the layers of an image.

In a future GEGL-based GIMP, layers can also be "algorithmic", for example: a blurring layer. (Photoshop calls these "adjustment layers".). Layers can also form a general directed acyclic graph, not just a linear stack as now.

--tml

On Wed, Nov 02, 2005 at 12:32:27AM +0200, Tor Lillqvist wrote:

In a future GEGL-based GIMP, layers can also be "algorithmic", for example: a blurring layer. (Photoshop calls these "adjustment layers".). Layers can also form a general directed acyclic graph, not just a linear stack as now.

Stop it! You're making me drool!

Brannon,

This question has been asked many times on this list and every time it is GEGL is described as the solution. When I tossed out the link to the GEGL site I did this sort of "tong in cheek" knowing that GEGL was not moving along at a very good pace. As you found out from the other responses GEGL could really use someone that would take on a leadership role and push things forward. To my way of thinking getting more than 8 bits/channel is the next major hurdle that GIMP needs to get over. Of course, unless someone steps up and starts moving GEGL ahead or some other solution is selected it will either never happen or it will be a long way off.

Perhaps you could consider taking on that leadership role? Or perhaps there is someone else here that could step up and take this on? I would consider it myself but I am the lead developer on another open source project and I simply don't have the time needed to do this.

Hal

On Monday 31 October 2005 01:11 pm, Brannon King wrote:

So I was told to see the GEGL info.

That website (gegl.org) drastically needs a FAQ. Perhaps someone can answer these questions for me:

1. Is GEGL made to replace a certain core piece of GIMP or is it made to reroute data somehow? 2. Why is it not part of the GIMP core currently? 3. Is it activelly being worked on? Is its mailing list still used?
4. It appears to just be an API. Why would using this be better than changing the current GIMP core to support 16bit channels directly? Or are we planning to do just that and just use the GEGL API data structures and constructs?
5. How close is the GEGL code to usable? 6. Will it even work with the current GIMP codebase? 7. Has anyone worked on a merge plan for combining GEGL work with the current GIMP codebase?

On Wednesday 02 November 2005 08:02, Hal V. Engel wrote:

Or perhaps there is someone else here that could step up and take this on?

If it's just _managing_ the repository, nagging people for patches etc, doing the occasional test build etc, then I volunteer. My gfx coding ski1lz are very rusty, but if I can be gorm on the axle enough to actually make things happen, I'll do it.

Cheers; Leon