RSS/Atom feed Twitter
Site is read-only, email is disabled

More basic questions

This discussion is connected to the gegl-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.

2 of 2 messages available
Toggle history

Please log in to manage your subscriptions.

More basic questions Todd Relyea 28 Jan 14:33
More basic questions Øyvind Kolås 30 Jan 10:44
Todd Relyea
2006-01-28 14:33:23 UTC (about 18 years ago)

More basic questions

I apologize for another round of basic GEGL questions...

To start with, I'm an electrical engineer with a programming background (multiple languages), and like many others I'm a fan of GIMP and would like to see it's development move forward (higher bit depth, CMYK, etc.). Working on GEGL and getting it in to usable shape seems to be where the next big leap for GIMP will come from, and like many others, I've been slogging through the GEGL code trying to make sense of how it's supposed to work.

For those who haven't read it, I thought that /docs/geglClasses.html was very informative on how gegl is intended to work and be used.

So in no particular order:

- Has there been a clear delineation made between the functionality of the future GIMP front end and GEGL?

The todo and bugzilla:

There are 7 bugs listed in bugzilla, but they're all pretty old. Do they actually reflect things that need to be done against the current code base?

Same question for the 'todo' on the gegl web site and CVS.

Lastly, what is the absolute minimum that needs to be done in order for gegl to be minimally usable? Reading through the docs and mailing list, it looks like some work needs to be done on the buffers, and then maybe create a very basic front end so people can actually play with the library, even if all of the functionality isn't implemented yet.

Todd

Øyvind Kolås
2006-01-30 10:44:19 UTC (about 18 years ago)

More basic questions

* Todd Relyea [060130 10:17]:

- Has there been a clear delineation made between the functionality of the future GIMP front end and GEGL?

All image processing (pixel modifying routines) should _eventually_ be moved to GEGL. The interface to GEGL should be the Directed Acyclic Graph describing processing operations. (A way to look up available nodes, and their parameters is needed as well, it might be possible to recycle some of the PDB (Procedural Data Base) in current GIMP to do this.

The todo and bugzilla:

There are 7 bugs listed in bugzilla, but they're all pretty old. Do they actually reflect things that need to be done against the current code base?

I have not even looked at the bugzilla, my guess is that if we are going to start using bugzilla again it probably makes sense to start with a clean slate. I'll try to find time to go through the list and figure out which bugs can be closed.

Same question for the 'todo' on the gegl web site and CVS.

That TODO was written during the code cleanup this summer and can be seen as a tentative roadmap written while trying to orient myself in the code base.

Lastly, what is the absolute minimum that needs to be done in order for gegl to be minimally usable?

Reading through the docs and mailing list, it looks like some work needs to be done on the buffers.

Yes the buffers is the main outstanding thing right now, this summer/beginning of the autumn I coded babl http://pippin.gimp.org/babl/ for generic and extendable pixel format (bitdepth and color space) conversions. This has some overlap with what is already in the gegl/image/ code which also has code dealing with color models and color spaces, babl does work (it evolved from code in gggl, and my gggl is currently using babl).

I do not feel confident enough to attack the gegl/image folder, and thus have started working with buffer representation elsewhere. http://pippin.gimp.org/horizon/ contains my buffer experiments. The result is that I know understand most of the issues that gegl/image is trying to solve but I have not exercised the code enough to have a firm grasp of API requirements.

The currently nice aspects of my tile based bufffer in horizon is that the buffer is unbounded, and it contains an automatically updated image pyramid for efficient scaled down views.

then maybe create a very basic front end so people can actually play with the library, even if all of the functionality isn't implemented yet.

Once it is possible to set up graphs and process them. A first minimal set of ops would quite probably be png_load, png_save, display, over and a single point based op.

/Øyvind K.