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
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 <sven@xxxxxxxx> wrote:
Hi,
The current GEGL integration is minimal. Let me try to outline how batch
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.
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.
Well, you could do it with GEGL. And all GEGL operations could be
> 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.
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@xxxxxxxxxxxxxxxxxxxxxx https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
