Joseph Miller wrote:

I have to work with a lot of website images so I end up doing a lot of resizing. I kept running into problems though where I would resize a whole set of layers, then find out I made them to large or too small. But I wouldn't be able to know this until I had them laid out on the image and could visually see the result. Since git Gimp has support for layer trees now (woo!) I figured this would be the easiest way to implement the feature. I just got this arranged about 20 minutes ago so I have not done a whole lot of testing. I also don't really know much about Gimp internals. I am looking for comments to my approach. Should I be moving in a different direction? I would like to add brightness-contrast non-destructive editing next, then maybe some color correction.

Hi Joseph!

Interesting patch, but it is unfortunately in the wrong direction. Non-destructive scaling needs to be implemented with GEGL and not by hijacking layer group semantics.

Also, you should submit patches with git format-patch as described here: http://gimp.org/bugs/howtos/submit-patch.html

But anyway, it's great to see a fresh mind hack on GIMP, keep those patches coming!

Best regards,
Martin

Joseph Miller wrote:

Interesting patch, but it is unfortunately in the wrong direction. Non-destructive scaling needs to be implemented with GEGL and not by hijacking layer group semantics.

Thanks for the link on the patch format. I'll look over that straight away. Would you explain how I should go about doing this with GEGL? Do I just need to change my approach in gimpgrouplayernd.*? Since I am not familiar with GIMP or GEGL development, a quick outline for what I need to do and where I need to make my entry points would help me a great deal.
I am at this point looking for drop-in functionality. I know that once GEGL is fully integrated this type of approach would be obsolete. I would be OK with that *if* GEGL is not ready for this type of drop-in addition. I would also be happy to work on GEGL as well, but I need something I can use pretty quickly. I would be thankful for any direction you can provide.

With GEGL, this will be done through a scale node, like "gegl:transform", in the image graph. The code to manage this probably will not end up in about the same size as what you have already, except it will use GEGL API instead of GIMP's pixel region APIs. We have already ported the projection to GEGL, so simply look at the existing GEGL code (git grep gegl_) and extrapolate to get a good estimate on how a "gegl:transform" node would be added to the graph.

And while I'm at it I can mention that your code have some coding style issues. Introducing an abbreviation like "nd" for "non-destructive" is too short-sighted, so it is better to spell that out. Otherwise we will forget what it stands for. And the opening brace for gimp_group_layernd_update_scale() is not on a separate line. This is not a problem if it's a local drop-in functionality hack of course.

Hope this helps in some way, Martin

Joseph Miller wrote:

With GEGL, this will be done through a scale node, like "gegl:transform", in the image graph. The code to manage this probably will not end up in about the same size as what you have already, except it will use GEGL API instead of GIMP's pixel region APIs. We have already ported the projection to GEGL, so simply look at the existing GEGL code (git grep gegl_) and extrapolate to get a good estimate on how a "gegl:transform" node would be added to the graph.

Is this projection already usable by the GIMP interface?

Well, the user interface itself doesn't use GEGL, but if you mean "how do I make GIMP use GEGL for image compositing?", the answer is that you just turn it on with View -> Use GEGL.

[...] Looks like it GEGL has
support for multithreading? I just got a quad-core and I'm anxious for it to improve my productivity wherever possible.

GEGL does not yet do multi threaded, but it a planned feature. It will happen transparently to clients though so the GIMP code will not (should not have to) bother.

/ Martin

Hi,

On Sun, 2009-12-20 at 08:53 +0100, Martin Nordholts wrote:

GEGL does not yet do multi threaded, but it a planned feature. It will happen transparently to clients though so the GIMP code will not (should not have to) bother.

As far as I know the version in git trunk does use multiple threads (and thus multiple processors) if you pass the --enable-mt option to the configure script. This is still quite experimental though, but it can be tested and I assume that Øyvind would appreciate any help to finish this.

Sven

On Sat, 2009-12-19 at 08:47 -0500, Joseph Miller wrote:

I have to work with a lot of website images so I end up doing a lot of resizing. I kept running into problems though where I would resize a whole set of layers, then find out I made them to large or too small. But I wouldn't be able to know this until I had them laid out on the image and could visually see the result. Since git Gimp has support for layer trees now (woo!) I figured this would be the easiest way to implement the feature. I just got this arranged about 20 minutes ago so I have not done a whole lot of testing. I also don't really know much about Gimp internals. I am looking for comments to my approach. Should I be moving in a different direction? I would like to add brightness-contrast non-destructive editing next, then maybe some color correction.

Use of layer-groups for this is definitely not the right approach. We want non-destructive editing and actually all of the work that has gone into porting GIMP over to GEGL has a primary goal and that is non-destructive editing. However adding this now by abusing a totally unrelated feature (layer groups) only makes it more difficult to accomplish this goal. So the net effect of your approach would be that it takes even longer before GIMP becomes a non-destructive image editor.

So what should be done instead? The way to go is clearly to extend use of GEGL in GIMP. If the Scale tool and other Scale operations work by inserting a "scale" node into the graph instead of destructively converting the image data, then we are almost there. The same should be done for all color correction tools. Currently they can make use of GEGL, but they do that in a destructive way because this part of the code was added before we even had a GEGL projection in GIMP.

I hope that we can motivate you to work on the GEGL graph in GIMP so that it can not only be used to project the image data, but also to do some of the image processing.

Sven

Joseph Miller wrote:

I hope that we can motivate you to work on the GEGL graph in GIMP so that it can not only be used to project the image data, but also to do some of the image processing.

I would like to try. I have not been able to access www.gegl.org for the documentation.

gegl.org is down for me too, but the website is built from the source code in the git repository so if you have cloned the GEGL repo you already have the available documentation

/ Martin