Hi,

On Mon, 2008-03-24 at 23:27 -0600, Joshua Stratton wrote:

I recently setup a proposal for Google Summer of Code that involves a gallery-style batch processor--a separate window that could display various sorting routines on images based on brightness, size, energy level, etc. Images could be grouped into sets that could be batch-processed like having all the selected or stacked images normalized to filtered with a sepia effect. I was wondering if anyone would find this useful.

I am sure that many users would find this useful.

I know several applications already provide some of this functionality outside of GIMP, but I believe they can be done better. For example, Dave's batch processor provides batch-processing in GIMP in the form of a plugin, but lacks visual thumbnails of the various images. Other applications don't have the cross-platform penetration that GIMP has.

The main problem with approaches such as Dave's batch processor is that it only allows a very limited set of operations. It probably does this because it has to implement it's own user interface for each of the allowed operations. In my opinion, this is a major drawback. GIMP has a lot of functionality that would be interesting to use in a batch process and the batch processor shouldn't limit you to a few.

We have a long-term plan to solve this and it is based on the GEGL port. I wonder what your plans about this are. Please tell us more about them.

Sven

Joshua Stratton wrote:

Does anyone have any comments about this proposal?

If you can build the svn-trunk version of gimp (which by the way is a very useful thing to do if you are interested in soc), you can find there a new "gegl tool" that allows a long list of operations to be performed, but has a pretty weak user interface. (It's very buggy too right now.) Turning this into something that users can actually work with, and use for gui-based batch operations, would be a pretty valuable contribution.

-- Bill

Hi,

On Tue, 2008-03-25 at 10:06 -0700, Bill Skaggs wrote:

If you can build the svn-trunk version of gimp (which by the way is a very useful thing to do if you are interested in soc), you can find there a new "gegl tool" that allows a long list of operations to be performed, but has a pretty weak user interface. (It's very buggy too right now.) Turning this into something that users can actually work with, and use for gui-based batch operations, would be a pretty valuable contribution.

The GEGL tool is just a playground for developers. Something that allows us to play with GEGL. I don't think we ever want to expose this to users. So I am not sure if we should base a GSoC project on it.

It's correct though that some ideas for a possible batch function could be taken from this tool.

Sven

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

Hi,

2008/3/26, Sven Neumann :

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.

Do you mean every stroke path like interactive paint tool MUST become an graph nodes ?
Or do you mean only some specific operations (one that is suitable for batch) are represented as gegl node, and rest of the operations can still modify image directly ?
If we chose first policy, the operation nodes quickly be flooded with enormous amount of
stroke path history for users who use GIMP as a paint tool.

I believe that we should classify operations into destructive ones (like paint brush) and
non-destructive ones (like filters and rotations etc.) , and user can use combination of destructive and non-destructive operations in some ways.

Or we should allow users to blit a part of the nodes into newly created image to save
memory space by discarding some of the operation history.

Please let me know the treatment of the destructive editing operations in future gimp.
--
Souichi TAKASHIGE

Hi,

On Thu, 2008-03-27 at 00:55 +0900, Souichi TAKASHIGE wrote:

Do you mean every stroke path like interactive paint tool MUST become an graph nodes ?

Probably not an individual graph node, but it will be kept in a paint operation node which itself stores each stroke so that it can be edited later. At least that's the theory. As far as I know Pippin is currently working on a paint core in GEGL. I suggest that you ask further questions about this on the GEGL mailing-list.

Sven