On Wednesday 17 November 2004 23:02, Joseph Heled wrote:

Hi,

I open a 3038x2012 photo (gimp 2.2-pre1). The caption below the image says 46.9 MB I add a layer with Layer/New Layer. The caption says 70.3 MB I delete the layer. Caption stays 70.3 MB I Layer/New Layer again. The caption says: 93.7 MB I delete the layer. Caption stays 93.7 MB

Should I believe the numbers or not? I understand the gimp might be allocating memory and keeping it, but it does not mean the size of the image keep growing indefinitely? What am I missing?

The information is still ther, as the layer deletion can be undone.

Open the "undo history" dialog, and hit the "clear undo history" button - that is what you were missing. :-)

Thanks, Joseph

Joseph Heled wrote:

Should I believe the numbers or not? I understand the gimp might be allocating memory and keeping it, but it does not mean the size of the image keep growing indefinitely? What am I missing?

I believe that total also includes the memory used for undo. So, depending on your undo settings, deleted layers may still be kept in memory.

Philip

On Thu, Nov 18, 2004 at 02:02:27PM +1300, Joseph Heled wrote:

I open a 3038x2012 photo (gimp 2.2-pre1). The caption below the image says 46.9 MB I add a layer with Layer/New Layer. The caption says 70.3 MB I delete the layer. Caption stays 70.3 MB I Layer/New Layer again. The caption says: 93.7 MB I delete the layer. Caption stays 93.7 MB

Should I believe the numbers or not? I understand the gimp might be allocating memory and keeping it, but it does not mean the size of the image keep growing indefinitely? What am I missing?

i wonder if it is the undo in the memory.

carol

Meanwhile, a hint on this undo subject for script/plugin writers: I found out it to be more eficient in memory usage, if aplicable, of course, to create a new image, disable undo in it (I cannont tell the difference between freeze/disable so far), and do your script stuff in there. When finalizing, copy your resulting drawable back to the original image.

gimp_image_undo_group_start won't save your memory.

BTW, some of the included scheme scripts could benefit from this.

JS ->

Which is the scheme script you are using?

It needs to be fixed anyway, as I posted on my other e-mail.

JS ->

On Wednesday 17 November 2004 23:51, Joseph Heled wrote:

Thanks for all of you who clarified this. My setting are Minimal number of undo levels - 20
Maximum Undo Memory - 64M

I guess the two are in conflict for large images. I like a fairly liberal number of undo's, yet I did not realize the size can balloon in a such a way and hit 1.2G after a few applications of a scheme script (which makes liberal use of new layers), which brings gimp and the system to a long minutes of swapparoa fun.

So, is there a way to limit the size per image? Or a better way to set up a machine with 750MB of memory and a large swap?

Thanks, Joseph

Joao S. O. Bueno Calligaris wrote:

On Wednesday 17 November 2004 23:02, Joseph Heled wrote:

Hi,

I open a 3038x2012 photo (gimp 2.2-pre1). The caption below the image says 46.9 MB I add a layer with Layer/New Layer. The caption says 70.3 MB I delete the layer. Caption stays 70.3 MB I Layer/New Layer again. The caption says: 93.7 MB I delete the layer. Caption stays 93.7 MB

Should I believe the numbers or not? I understand the gimp might be allocating memory and keeping it, but it does not mean the size of the image keep growing indefinitely? What am I missing?

The information is still ther, as the layer deletion can be undone.

Open the "undo history" dialog, and hit the "clear undo history" button - that is what you were missing. :-)

Thanks, Joseph

Hi,

Joseph Heled writes:

Thanks for all of you who clarified this. My setting are Minimal number of undo levels - 20
Maximum Undo Memory - 64M

Reduce the number of undo steps. You are telling GIMP that it must always keep at least 20 undo steps per image, no matter how much memory that will need.

So, is there a way to limit the size per image? Or a better way to set up a machine with 750MB of memory and a large swap?

You should make sure that your tile-cache-size is set reasonably large. I would suggest to use at least 512MB.

Sven

Hi,

perhaps it would help if I explain the concept of the two undo settings again. Let's see what the man-page says...

(undo-levels 5)

Sets the minimal number of operations that can be undone. More undo levels are kept available until the undo-size limit is reached. This is an integer value.

(undo-size 16M)

Sets an upper limit to the memory that is used per image to keep operations on the undo stack. Regardless of this setting, at least as many undo-levels as configured can be undone. The integer size can contain a suffix of ’B’, ’K’, ’M’ or ’G’ which makes GIMP interpret the size as being specified in bytes, kilobytes, megabytes or gigabytes. If no suffix is specified the size defaults to being specified in kilobytes.

So we have two settings here and it isn't completely obvious how these two work together. GIMP 1.2 used to have one setting only, the number of undo levels. That was simple but had the problem that if you for example repositioned a layer a few times you would fill the undo stack with these move operations. Even though the information that is needed for undoing a layer move takes up only a couple of bytes, the undo stack only kept the number of configured undo steps. So you had to choose a rather large limit here. Using a large value on the other hand means that if you do a couple of color adjustments on the image (which take quite a lot of memory) your undo stack will grow unreasonably large and you will run out of memory.

With GIMP 2.0 we added the new setting undo-size. This allows you to tell GIMP that you want to keep undo steps until that size limit (which is per image) is hit. If you choose a reasonably large value here you will be able to undo a lot of small operations. Only operations that affect a lot of pixels will cause this limit to be exceeded. Now here's where the undo-levels setting jumps in. GIMP will always keep at least that number of undo steps, even if that means exceeding the configured undo-size limit.

This allows you to setup GIMP so that you can always undo at least as many steps as configured for undo-levels but GIMP will not start to throw away undo steps as long as the configured undo-size limit isn't reached. It's up to you to find a well-balanced setup here.

Sven

Hi Joseph,

Joseph Heled wrote:

The caption below the image says 46.9 MB I add a layer with Layer/New Layer. The caption says 70.3 MB I delete the layer. Caption stays 70.3 MB I Layer/New Layer again. The caption says: 93.7 MB I delete the layer. Caption stays 93.7 MB

Should I believe the numbers or not? I understand the gimp might be allocating memory and keeping it, but it does not mean the size of the image keep growing indefinitely? What am I missing?

When you delete the layer, the delete step is registered in the undo stack. The undo stack is stored with the image in memory, so the layer actually moves from the layer stack to the undo stack. To change this behaviour, you could reduce the minimum number of undo steps saved to 1, say, which will discard the old data as soon as the undo stack goes past that number of steps (if you're making small changes like visibility changes, for example, your undo stack will grow much more, since the second undo parameter is the memory limit of the undo stack once you go past the minimum number of undo steps).

Cheers, Dave.

Here's a thought - at some point, we expect that there will be a recording mechanism for GIMP, and when that happens, perhaps some coupling between it and the undo mechanism would help reduce some memory requirements for the undo mechanism.

If we know whether a user action is deterministic, the undo action could rewind to a prior checkpoint where the image had been kept intact, and the actions since that time could be reapplied to advance up to the previous action.

When a nondeterministic action occurs, a checkpoint mechanism would still need cause the image (or a portion of it) to be kept, but that would not be necessary for each step.

Since creating a new layer is deterministic, deleting the layer should be able to be undone replaying the creation of the empty layer, thus, the undo action doesn't need to keep the empty layer in memory.

Exceptions: Actions that take input from external sources would need to be treated like nondeterministic actions, causing a checkpoint to occur. Actions that use random numbers could record the random number seed that is used and be treated as deterministic.

Just a thought...

_-T

_________________

Hi,

"shaneyfelt@juno.com" writes:

Here's a thought - at some point, we expect that there will be a recording mechanism for GIMP, and when that happens, perhaps some coupling between it and the undo mechanism would help reduce some memory requirements for the undo mechanism.

[snip]

Sounds exactly like the plans we made at GimpCon 2000.

Sven

Hi David, the onlything I still need is resizing/ rotating of patterns on the fly while I paint from the clone tool- or fill the images in. Any quotes ? :)
- Cam

David Neary wrote:

Hi Cam,

You sent this to me personally - would you mind sending it to the list?

I think your ideas are pretty good, by the way.

Also - are you interested in fleshing out properly the idea of bounties again? The response to your last request was poor, but I think that we could formalise something by working (with Sven) on a list of 5 or 10 bounties, and if we put a reasonable dollar figure with the features, and coordinate the bounty program with the release schedule, I think we can get a decent response.

Cheers, Dave.

Campbell J Barton wrote:

To me this seams simple

There are 2 different things- 1) Image Memory usage. (What it currently is)

2) Image Size (flat/expanded) - flat simply bing the memory used by the image assuming is was flattened expanded being the size of each layer added together - undo's etc Ignored.

or even simpler

1) memory used by image

2) roughly the size of an umcompressed XCF

3) the size of the image as an uncompressed tiff/bmp whatever.

An option for each would be nice :)

- Cam

David Neary wrote:

Hi Joseph,

Joseph Heled wrote:

The caption below the image says 46.9 MB I add a layer with Layer/New Layer. The caption says 70.3 MB I delete the layer. Caption stays 70.3 MB I Layer/New Layer again. The caption says: 93.7 MB I delete the layer. Caption stays 93.7 MB

Should I believe the numbers or not? I understand the gimp might be allocating memory and keeping it, but it does not mean the size of the image keep growing indefinitely? What am I missing?

When you delete the layer, the delete step is registered in the undo stack. The undo stack is stored with the image in memory, so the layer actually moves from the layer stack to the undo stack. To change this behaviour, you could reduce the minimum number of undo steps saved to 1, say, which will discard the old data as soon as the undo stack goes past that number of steps (if you're making small changes like visibility changes, for example, your undo stack will grow much more, since the second undo parameter is the memory limit of the undo stack once you go past the minimum number of undo steps).

Cheers, Dave.

Sounds exactly like the plans we made at GimpCon 2000.

Sven

Sorry I wasn't there. Perhaps you can meet in Hawaii sometime.

_________________

Hi,

"shaneyfelt@juno.com" writes:

Sounds exactly like the plans we made at GimpCon 2000.

Sorry I wasn't there. Perhaps you can meet in Hawaii sometime.

That sounds like a lovely idea.

Sven

I've got a plugin that attaches to an existing (displayed) image, and replaces it with a different image:

gint newImage = gimp_file_load(...); gimp_displays_reconnect(oldImage, newImage); gimp_image_delete(oldImage);

Problem is that (I think) the new image now has two references, so when the user closes the image display the image is not deleted. If that's right, is there any way to remove the extra reference? If not, what's going on?

Hi,

David Hodson writes:

I've got a plugin that attaches to an existing (displayed) image, and replaces it with a different image:

gint newImage = gimp_file_load(...); gimp_displays_reconnect(oldImage, newImage); gimp_image_delete(oldImage);

Problem is that (I think) the new image now has two references, so when the user closes the image display the image is not deleted. If that's right, is there any way to remove the extra reference?

If that is what happens, then that would be a bug that needs fixing. Could you please try with GIMP 2.2-pre2? If the image still shows up in the "Images" dialog after you closed the last display, then please file a bug report for it.

Sven

Hi,

I've just tried this with GIMP 2.2-pre2 from the Script-Fu console and you are right that the reference handling is somewhat confusing. Perhaps gimp_displays_reconnect() should hand the reference over to the display just as gimp_display_new() does. That would however mean that if you reconnected the display again your image would be gone since the last reference on it just got dropped.

So I think the current behaviour is coorect but should perhaps be documented better. Your plug-in will have to call gimp_image_delete() on the new image in order to drop the reference it holds on it. Here's the example you gave:

gint newImage = gimp_file_load (...); gimp_displays_reconnect (oldImage, newImage); gimp_image_delete (oldImage);

That last line is wrong since you never owned a reference on that image and it is already gone at that point. It should read instead:

gint newImage = gimp_file_load (...); gimp_displays_reconnect (oldImage, newImage); gimp_image_delete (newImage);

Sven

Sven Neumann writes:

Hi,

I've just tried this with GIMP 2.2-pre2 from the Script-Fu console and you are right that the reference handling is somewhat confusing. Perhaps gimp_displays_reconnect() should hand the reference over to the display just as gimp_display_new() does. That would however mean that if you reconnected the display again your image would be gone since the last reference on it just got dropped.

So I think the current behaviour is coorect but should perhaps be documented better. Your plug-in will have to call gimp_image_delete() on the new image in order to drop the reference it holds on it. Here's the example you gave:

gint newImage = gimp_file_load (...); gimp_displays_reconnect (oldImage, newImage); gimp_image_delete (oldImage);

That last line is wrong since you never owned a reference on that image and it is already gone at that point. It should read instead:

gint newImage = gimp_file_load (...); gimp_displays_reconnect (oldImage, newImage); gimp_image_delete (newImage);

I tend to disagree.

IMHO we should change the PDB wrapper to

(1) work as documented (fail if the new image already has a display). (2) also fail if the old image has no display. (3) make it take over the reference count on success.

It's impossible to call gimp_image_delete() on an image which has a display, so both above pieces of code won't work. and in fact this is impossible to get right with the current implementation of gimp_displays_reconnect().

ciao, --mitch

FYI, I opened a bug for this issue:

http://bugzilla.gnome.org/show_bug.cgi?id=159051

Michael Natterer writes:

Sven Neumann writes:

Hi,

I've just tried this with GIMP 2.2-pre2 from the Script-Fu console and you are right that the reference handling is somewhat confusing. Perhaps gimp_displays_reconnect() should hand the reference over to the display just as gimp_display_new() does. That would however mean that if you reconnected the display again your image would be gone since the last reference on it just got dropped.

So I think the current behaviour is coorect but should perhaps be documented better. Your plug-in will have to call gimp_image_delete() on the new image in order to drop the reference it holds on it. Here's the example you gave:

gint newImage = gimp_file_load (...); gimp_displays_reconnect (oldImage, newImage); gimp_image_delete (oldImage);

That last line is wrong since you never owned a reference on that image and it is already gone at that point. It should read instead:

gint newImage = gimp_file_load (...); gimp_displays_reconnect (oldImage, newImage); gimp_image_delete (newImage);

I tend to disagree.

IMHO we should change the PDB wrapper to

(1) work as documented (fail if the new image already has a display). (2) also fail if the old image has no display. (3) make it take over the reference count on success.

It's impossible to call gimp_image_delete() on an image which has a display, so both above pieces of code won't work. and in fact this is impossible to get right with the current implementation of gimp_displays_reconnect().

ciao, --mitch

Michael Natterer wrote:

Sven Neumann writes:

Here's the example you gave:

gint newImage = gimp_file_load (...); gimp_displays_reconnect (oldImage, newImage); gimp_image_delete (oldImage);

That last line is wrong since you never owned a reference on that image and it is already gone at that point. It should read instead:

gint newImage = gimp_file_load (...); gimp_displays_reconnect (oldImage, newImage); gimp_image_delete (newImage);

It's impossible to call gimp_image_delete() on an image which has a display, so both above pieces of code won't work. and in fact this is impossible to get right with the current implementation of gimp_displays_reconnect().

(Note: I haven't updated to 2.2pre yet, I'm still running 2.0.3.) In fact, if I remove the gimp_image_delete(oldImage), then the old image does not get removed when the display is reconnected.

If anyone wants to investigate further, the code is at:

http://members.ozemail.com.au/~hodsond/fileSeq.html