RSS/Atom feed Twitter
Site is read-only, email is disabled

Layer groups seriously broken - huge resource hog

This discussion is connected to the gimp-user-list.gnome.org mailing list which is provided by the GIMP developers and not related to gimpusers.com.

This is a read-only list on gimpusers.com so this discussion thread is read-only, too.

8 of 8 messages available
Toggle history

Please log in to manage your subscriptions.

Layer groups seriously broken - huge resource hog BWK 16 Jun 10:38
  Layer groups seriously broken - huge resource hog Ofnuts 17 Jun 14:23
   Layer groups seriously broken - huge resource hog BWK 18 Jun 15:27
    Layer groups seriously broken - huge resource hog Richard via gimp-user-list 19 Jun 00:20
     Layer groups seriously broken - huge resource hog BWK 19 Jun 15:13
      Layer groups seriously broken - huge resource hog Daniel Smith via gimp-user-list 19 Jun 19:38
      Layer groups seriously broken - huge resource hog Liam R E Quin 20 Jun 04:55
      Layer groups seriously broken - huge resource hog Richard via gimp-user-list 21 Jun 02:14
2018-06-16 10:38:26 UTC (almost 6 years ago)
postings
24

Layer groups seriously broken - huge resource hog

I love Gimp. I started using it about a year ago and it is the second most used piece of software on my computers. I often use it on two of my computers at the same time. I do stuff with it mostly with aerial photo mosaics up to 500 megapixels - aerial photo tiles joined together with other aerial photos overlaid over the top of them. With the new unified transform tool in Gimp 2.10 an aerial photo overlay can be completed in one step of transformation thus maximising the quality and speeding up the work. The software is brilliant for this.

Nevertheless there seems to be significant shortcomings in the implementation of layer groups in Gimp. I started using them because I had a lot of layers in my projects and I wanted to keep everything tidy. But as my projects have grown, I have found that layer groups are a huge waste of resources. With the biggest project, the file size of the project doubled from 4 GB to 8 GB when layer groups were used, with exactly the same layers. Part of creating these aerial photos is to split them into tiles to be loaded into a GIS for mapping. This requires resizing the canvas to crop the boundaries to a tile boundary and then exporting the tile out as a JPG. Most of these tiles are only 4800x7200 pixels that should not really be a problem for the computer. But with layer groups it takes about 15 minutes to do the canvas resize with the disk constantly churning. Without layer groups it only takes about 15 seconds. The export itself is much faster with far less disk churning as well.

I only discovered this by accident when in one of my projects Gimp constantly crashed when saving the project as soon as I added more than three layers to a layer group. Obviously Gimp is broken in that area (and doesn't throw any kind of error message or exception either, it just quits) but the result of having to take out the layer groups I was putting in and working without them has had the unexpected benefit of a huge time saving after allowing for a lost day trying to work out what the crashing was about.

If this feature is going to be any good in Gimp in the future the implementation of it needs serious attention.

Ofnuts
2018-06-17 14:23:03 UTC (almost 6 years ago)

Layer groups seriously broken - huge resource hog

On 06/16/18 12:38, BWK wrote:

I love Gimp. I started using it about a year ago and it is the second most used piece of software on my computers. I often use it on two of my computers at the same time. I do stuff with it mostly with aerial photo mosaics up to 500 megapixels - aerial photo tiles joined together with other aerial photos overlaid over the top of them. With the new unified transform tool in Gimp 2.10 an aerial photo overlay can be completed in one step of transformation thus maximising the quality and speeding up the work. The software is brilliant for this.

Nevertheless there seems to be significant shortcomings in the implementation of layer groups in Gimp. I started using them because I had a lot of layers in my projects and I wanted to keep everything tidy. But as my projects have grown, I have found that layer groups are a huge waste of resources. With the biggest project, the file size of the project doubled from 4 GB to 8 GB when layer groups were used, with exactly the same layers. Part of creating these aerial photos is to split them into tiles to be loaded into a GIS for mapping. This requires resizing the canvas to crop the boundaries to a tile boundary and then exporting the tile out as a JPG. Most of these tiles are only 4800x7200 pixels that should not really be a problem for the computer. But with layer groups it takes about 15 minutes to do the canvas resize with the disk constantly churning. Without layer groups it only takes about 15 seconds. The export itself is much faster with far less disk churning as well.

I only discovered this by accident when in one of my projects Gimp constantly crashed when saving the project as soon as I added more than three layers to a layer group. Obviously Gimp is broken in that area (and doesn't throw any kind of error message or exception either, it just quits) but the result of having to take out the layer groups I was putting in and working without them has had the unexpected benefit of a huge time saving after allowing for a lost day trying to work out what the crashing was about.

If this feature is going to be any good in Gimp in the future the implementation of it needs serious attention.

Layers groups are not meant to keep things tidy. They are meant to force the compositing order, like parentheses in a mathematical equation. Groups have their own opacity, blending mode (and layer mask in 2.10). Layers in a group are composed, resulting in a virtual layer, which is composed with the layers (or virtual layers from groups) in the parent level...

It is possible that layers groups add just enough memory to overflow the tile cache and force Gimp to work with a swap (this really slows tings down). See Edit>Preferences>System resources>Tile cache size and set it to as much as possible (your available RAM minus what you need for your system and other apps).

Something that can help keep things tidy in 2.10 is t use color tags on the layers.

2018-06-18 15:27:46 UTC (almost 6 years ago)
postings
24

Layer groups seriously broken - huge resource hog

Whilst I have played with settings recently to use an SSD partition for swap, this answer still doesn't address why the disk space usage is wasteful. The extra space not being used for anything worthwhile will fill up my disk much faster.

Layers groups are not meant to keep things tidy. They are meant to force
the compositing order, like parentheses in a mathematical equation. Groups have their own opacity, blending mode (and layer mask in 2.10). Layers in a group are composed, resulting in a virtual layer, which is composed with the layers (or virtual layers from groups) in the parent level...

It is possible that layers groups add just enough memory to overflow the
tile cache and force Gimp to work with a swap (this really slows tings down). See Edit>Preferences>System resources>Tile cache size and set it
to as much as possible (your available RAM minus what you need for your
system and other apps).

Something that can help keep things tidy in 2.10 is t use color tags on
the layers.

Richard via gimp-user-list
2018-06-19 00:20:46 UTC (almost 6 years ago)

Layer groups seriously broken - huge resource hog

Layer groups internally create a virtual layer representing their entire composited contents to speed up overall rendering of the image (at the topmost levels); a similar thing already occurs when you have a project containing text layers.

Alternatively, you mentioned your process involves resizing the image canvas as a means to 'crop' a given portion of the image out to a JPG? If this is your only performance bottleneck then finding a way to avoid that step should work around the issue entirely. How about trying these steps instead?

1- Create a rectangle selection of the desired export size (e.g. 4800x7200) at the desired location in the image

2- Edit > "Copy Visible" (copies from all rendered layers)

3- Paste as New Image

4- Export

-- Stratadrake strata_ranger@hotmail.com
--------------------
Numbers may not lie, but neither do they tell the whole truth.

From: gimp-user-list  on behalf of BWK 
Sent: Monday, June 18, 2018 8:27:47 AM
To: gimp-user-list@gnome.org
Cc: notifications@gimpusers.com
Subject: [Gimp-user] Layer groups seriously broken - huge resource hog

Whilst I have played with settings recently to use an SSD partition for swap,
this answer still doesn't address why the disk space usage is wasteful. The
extra space not being used for anything worthwhile will fill up my disk much
faster.

>Layers groups are not meant to keep things tidy. They are meant to
>force
>the compositing order, like parentheses in a mathematical equation.
>Groups have their own opacity, blending mode (and layer mask in 2.10).
>Layers in a group are composed, resulting in a virtual layer, which is
>composed with the layers (or virtual layers from groups) in the parent
>level...
>
>It is possible that layers groups add just enough memory to overflow
>the
>tile cache and force Gimp to work with a swap (this really slows tings
>down). See Edit>Preferences>System resources>Tile cache size and set
>it
>to as much as possible (your available RAM minus what you need for
>your
>system and other apps).
>
>Something that can help keep things tidy in 2.10 is t use color tags
>on
>the layers.

--
BWK (via www.gimpusers.com/forums)
2018-06-19 15:13:18 UTC (almost 6 years ago)
postings
24

Layer groups seriously broken - huge resource hog

I doubt you've ever tried doing a selection rectangle to that size and getting it exactly the right size and boundaries. It is a very slow and fiddly operation.

Layer groups internally create a virtual layer representing their entire composited contents to speed up overall rendering of the image (at the topmost levels); a similar thing already occurs when you have a project containing text layers.

Alternatively, you mentioned your process involves resizing the image canvas as a means to 'crop' a given portion of the image out to a JPG? If this is your only performance bottleneck then finding a way to avoid that step should work around the issue entirely. How about trying these steps instead?

1- Create a rectangle selection of the desired export size (e.g. 4800x7200) at the desired location in the image

2- Edit > "Copy Visible" (copies from all rendered layers)

3- Paste as New Image

4- Export

-- Stratadrake strata_ranger@hotmail.com
--------------------
Numbers may not lie, but neither do they tell the whole truth.

Daniel Smith via gimp-user-list
2018-06-19 19:38:30 UTC (almost 6 years ago)

Layer groups seriously broken - huge resource hog

Also, I have found in graphics the more cores you can have, the better. Dan

Sent from my iPhone

On Jun 19, 2018, at 11:13 AM, BWK wrote:

I doubt you've ever tried doing a selection rectangle to that size and getting it exactly the right size and boundaries. It is a very slow and fiddly operation.

Layer groups internally create a virtual layer representing their entire composited contents to speed up overall rendering of the image (at the topmost levels); a similar thing already occurs when you have a project containing text layers.

Alternatively, you mentioned your process involves resizing the image canvas as a means to 'crop' a given portion of the image out to a JPG? If this is your only performance bottleneck then finding a way to avoid that step should work around the issue entirely. How about trying these steps instead?

1- Create a rectangle selection of the desired export size (e.g. 4800x7200) at the desired location in the image

2- Edit > "Copy Visible" (copies from all rendered layers)

3- Paste as New Image

4- Export

-- Stratadrake strata_ranger@hotmail.com
--------------------
Numbers may not lie, but neither do they tell the whole truth.

--
BWK (via www.gimpusers.com/forums)
_______________________________________________ gimp-user-list mailing list
List address: gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list List archives: https://mail.gnome.org/archives/gimp-user-list

Liam R E Quin
2018-06-20 04:55:48 UTC (almost 6 years ago)

Layer groups seriously broken - huge resource hog

On Tue, 2018-06-19 at 17:13 +0200, BWK wrote:

I doubt you've ever tried doing a selection rectangle to that size and getting
it exactly the right size and boundaries. It is a very slow and fiddly operation.

You can use tool options to fix the size in the rectangle select tool, and for that matter the position, or make the rectangle and drag it to where you want it; alt and arrow keys may also work to move it.

You can also use image->canvas size, of course, if you know the positions you want.

I routinely do large rectangle selects, by the way. Did one that was probably about 15,000 pixels high yesterday, and then Fill with bg, and it was fast. I zoom in to adjust the rectangle as needed, use the ` key to zoom back out again, or control-shift-j to fit the image in the window, but i've been using the keystrokes for a long time :) If it's going slowly for you it might be you don't have enough memory. This desktop has 32GBytes of RAM and i have the tile cache set to 24G.

Liam

Liam Quin - web slave for https://www.fromoldbooks.org/
with fabulous vintage art and fascinating texts to read.
Click here to have the slave beaten.
Richard via gimp-user-list
2018-06-21 02:14:30 UTC (almost 6 years ago)

Layer groups seriously broken - huge resource hog

I doubt you've ever tried doing a selection rectangle to that size and

getting it exactly the right size and boundaries. It is a very slow and

fiddly operation.

Not necessarily, but as Liam pointed out there are various ways to reduce the fiddle factor: in the rectangle select's tool options you can specify a fixed size (width and height) so that you only have to worry about its positioning. You can set guides at the precise locations you need them so the selection rectangle can snap to them, and if all else fails you can fine-tune the position manually in the tool options, too.

-- Stratadrake strata_ranger@hotmail.com
--------------------
Numbers may not lie, but neither do they tell the whole truth.

From: gimp-user-list  on behalf of BWK 
Sent: Tuesday, June 19, 2018 8:13 AM
To: gimp-user-list@gnome.org
Cc: notifications@gimpusers.com
Subject: [Gimp-user] Layer groups seriously broken - huge resource hog

I doubt you've ever tried doing a selection rectangle to that size and getting
it exactly the right size and boundaries. It is a very slow and fiddly
operation.

--
BWK (via www.gimpusers.com/forums)