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. Josh 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 Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
