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.
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?
> Gimp-developer mailing list
Gimp-developer mailing list