Well, I guess I'm a little confused about the actual purpose of GEGL.  It
sounded like it would provide a more formal and robust interface for GIMP's
image processing.  GEGL might be a good choice if the current tools are hard
to interface with, but I really wanted all filters, for example, accesible
to the user.  It just seems like a waste of time to reimplement many of them
using GEGL unless they all will be reimplemented anyways in the future, in
which case I wouldn't mind implementing a lot of the filters, etc.

I just think that it would be easier using the current filters and migrate
them to GEGL later if needs be.


On Wed, Mar 26, 2008 at 2:01 AM, Sven Neumann <[EMAIL PROTECTED]> wrote:

> Hi,
> On Tue, 2008-03-25 at 07:40 -0600, Joshua Stratton wrote:
> > Well, I do not know the current status of GEGL in GIMP's code,
> > although I do believe it is the right  way to go (from the GEGL
> > presentations I have seen).  I was assuming much of GEGL's
> > implementation would be transparent to the user such as filter
> > operations (as in the user wouldn't know if GEGL is doing the
> > convolution or the original implementation).  I guess it would pretty
> > much depend on GEGL's integration status during the project.  Looking
> > at the current GIMP snapshot, it looks like GEGL is already integrated
> > into at least a good chunk of the code.
> The current GEGL integration is minimal. Let me try to outline how batch
> processing in a future GIMP would work:
> Whatever you do to the image is represented as a graph. If you are doing
> a series of operations on an image, then your graph boils down to a load
> operation, a chain of manipulations and a save operation. Now if you
> want to apply the same chain of manipulations to another image and save
> it to another file, all you need to do is to change the filenames in the
> load and save nodes. That is how batch processing in a future GIMP would
> work. You wouldn't need a dedicated UI for it. You could just say, do
> this same thing that I just did with this image with all images in this
> folder.
> >   I'm assuming I could do it all with GEGL if it is a complete
> > image-processing API.  I was not planning on having the user use any
> > XML like GEGL could process, but I certainly could add it.  I would
> > need some feedback from other developers as to what would be a good
> > interface, but I envisioned something similar to Adobe's Lightroom,
> > where photos were easily browsable, stackable, and hopefully most of
> > GIMP's operations (as opposed to a select subset) could be applied to
> > the group.
> Well, you could do it with GEGL. And all GEGL operations could be
> applied to the group. But all GEGL operations would need a user
> interface to specify their parameters. And GEGL doesn't provide that
> user interface. How So you would end up coding a completely new
> application and that doesn't sound like a good proposal for a GSoC
> project.
> Sven
Gimp-developer mailing list

Reply via email to