On Friday 18 February 2005 14:17, Mateusz Misiorny wrote:

Hi!

I am currently working on a poster, and it's huge (from the point of view of the amount of memory I have ;) ). Once in a while I have to post it to the mailing list for my people to see if they like it and tell me what to change. Every time I want to mail it I first have to save it (.xcf), then scale it down, save as jpg then undo the scaling or just close and load again. So I thought it would be great if there was an option in the save dialog to choose the size you want to save the image in. It could be hidden in the "Advanced Options" or something so that usually it wouldn't bother you. What do you think about this? Should I put up a reuqest on bugzilla for that? It shouldn't be too hard to implement, since it's just one more operation during saving (like flattening or so) and it would require copying the Scale Image dialog somewhere to the Save Dialog. It would save you undo memory, and time.

I don't think it's necessary. One can always write a small GIMP script that uses the PDB entries, to do all of this at once. If you want, I can show you how to write one, if you be more specific about what exactly you want to do, in your case.

Regards,

Shlomi Fish

--------------------------------------------------------------------- Shlomi Fish shlomif@iglu.org.il Homepage: http://www.shlomifish.org/

Knuth is not God! It took him two days to build the Roman Empire.

Hi,

Mateusz Misiorny writes:

I am currently working on a poster, and it's huge (from the point of view of the amount of memory I have ;) ). Once in a while I have to post it to the mailing list for my people to see if they like it and tell me what to change. Every time I want to mail it I first have to save it (.xcf), then scale it down, save as jpg then undo the scaling or just close and load again. So I thought it would be great if there was an option in the save dialog to choose the size you want to save the image in. It could be hidden in the "Advanced Options" or something so that usually it wouldn't bother you. What do you think about this? Should I put up a reuqest on bugzilla for that? It shouldn't be too hard to implement, since it's just one more operation during saving (like flattening or so) and it would require copying the Scale Image dialog somewhere to the Save Dialog. It would save you undo memory, and time.

No, this would only clutter the save dialog. It is already crowded enough. If we'd do that, next week someone will call for auto-whitebalance on save, adding a border and sending mail to grandma. No way.

Sven

Hi,

instead of just dismissing your suggestion, here's a suggestion for you: Write yourself a simple script that saves a JPEG preview of your image and installs itself next to the Save menu entry.

Sven

On Friday 18 February 2005 19:31, Sven Neumann wrote:

Hi,

Mateusz Misiorny writes:

I am currently working on a poster, and it's huge (from the point of view of the amount of memory I have ;) ). Once in a while I have to post it to the mailing list for my people to see if they like it and tell me what to change. Every time I want to mail it I first have to save it (.xcf), then scale it down, save as jpg then undo the scaling or just close and load again. So I thought it would be great if there was an option in the save dialog to choose the size you want to save the image in. It could be hidden in the "Advanced Options" or something so that usually it wouldn't bother you.
What do you think about this? Should I put up a reuqest on bugzilla for that? It shouldn't be too hard to implement, since it's just one more operation during saving (like flattening or so) and it would require copying the Scale Image dialog somewhere to the Save Dialog. It would save you undo memory, and time.

Mateusz,
I have two 1 liner script-fus to enable/disable undo . Maybe they can help you?

Try disabling script-fu previously to scale, then save as copy, and reload your image.

No, this would only clutter the save dialog. It is already crowded enough. If we'd do that, next week someone will call for auto-whitebalance on save, adding a border and sending mail to grandma. No way.

Sven
_______

Hi,
gwidion@mpc.com.br (2005-02-18 at 2053.55 -0200):

I am currently working on a poster, and it's huge (from the point of view of the amount of memory I have ;) ). Once in a while I have to post it to the mailing list for my people to see if they like it and tell me what to change. Every time I want to mail it I first have to save it (.xcf), then scale it down, save as jpg then undo the scaling or just close and load again. So I thought it would be great if there was an option in the save dialog to choose the size you want to save the image in. It could be hidden in the "Advanced Options" or something so that usually it wouldn't bother you.

Try disabling script-fu previously to scale, then save as copy, and reload your image.

I would go with duplicate image, scale the clone, save then close. No undo problems that way, xcf version stays untouched, both disk and memory.

GSR

On Saturday 19 February 2005 16:06, GSR - FR wrote:

Hi,

gwidion@mpc.com.br (2005-02-18 at 2053.55 -0200):

I am currently working on a poster, and it's huge (from the point of view of the amount of memory I have ;) ). Once in a while I have to post it to the mailing list for my people to see if they like it and tell me what to change. Every time I want to mail it I first have to save it (.xcf), then scale it down, save as jpg then undo the scaling or just close and load again. So I thought it would be great if there was an option in the save dialog to choose the size you want to save the image in. It could be hidden in the "Advanced Options" or something so that usually it wouldn't bother you.

Try disabling script-fu previously to scale, then save as copy, and reload your image.

I would go with duplicate image, scale the clone, save then close. No undo problems that way, xcf version stays untouched, both disk and memory.

Let X bre a Huge Amount of Memory (tm) taken by said image, and Y be A Couple Kilobytes (tm) used by scaled down version Your proccess:
- Initially using X memory
duplicate image -> now using x * 2 memory. scale image down, with UNDO active -> using x * 2 + Y memory discard copy-> back to using X memory.

My proccess: - Inittially using X memory
- Disable Undo for this image
- Scale down: Using Y memory.
- Save copy
- Revert: Using back X memory.

As you see, they are roughly equivalent, exepct that your method, in the intermediate steps, use twice as much memory. The slowdown complained about is probably due to Tile swapping .

Take your conclusions.

GSR

Am Freitag 18 Februar 2005 22:31 schrieb Sven Neumann:

No, this would only clutter the save dialog. It is already crowded enough. If we'd do that, next week someone will call for auto-whitebalance on save, adding a border and sending mail to grandma. No way.

Hello Sven,

I agree with you, but wouldn't it be nice to have once on a day something similar to the "file > automation" dialog in Photoshop?

There one can choose for example contact sheet or batch processing. In batch processing one can select an action (i.e. gimp-script), a folder for loading the files for processing and one for saving them, and in which kind the naming is to be managed, and so on.

I think, this could be something for later plans in the far future.

Kind regards

Gerhard

Joao S. O. Bueno Calligaris wrote:

- Initially using X memory
duplicate image -> now using x * 2 memory.

That shouldn't be true. The vast majority of the memory used by the duplicate is tile data which GIMP simply copy-on-write shares between the original and the duplicate. (Unless COW stuff got broken since I last checked, but I doubt it.)

--Adam

Hi,

Gerhard Gaußling writes:

I agree with you, but wouldn't it be nice to have once on a day something similar to the "file > automation" dialog in Photoshop?

There one can choose for example contact sheet or batch processing. In batch processing one can select an action (i.e. gimp-script), a folder for loading the files for processing and one for saving them, and in which kind the naming is to be managed, and so on.

I think, this could be something for later plans in the far future.

I think this is something that can be developed completely independently as a GIMP plug-in. And sure, I am waiting for someone to write this for several years already.

Sven

Hi,
gwidion@mpc.com.br (2005-02-20 at 0203.45 -0200):

Let X bre a Huge Amount of Memory (tm) taken by said image, and Y be A Couple Kilobytes (tm) used by scaled down version Your proccess:
- Initially using X memory
duplicate image -> now using x * 2 memory.

I assume there is Copy On Write, thus delaying real memory usage (and the bandwidth too) until the data changes. Lets see COW at work:

Just after launching gimp:

total used free shared buffers cached Mem: 514308 444404 69904 0 6180 137996 -/+ buffers/cache: 300228 214080 Swap: 264144 63140 201004

2000*2000 image created and plasma filter run:

total used free shared buffers cached Mem: 514308 500864 13444 0 6336 138012 -/+ buffers/cache: 356516 157792 Swap: 264144 63140 201004

script-fu console launched:

total used free shared buffers cached Mem: 514308 503428 10880 0 6372 138268 -/+ buffers/cache: 358788 155520 Swap: 264144 63140 201004

gimp-image-duplicate invoked once, id reported is 2:

total used free shared buffers cached Mem: 514308 503000 11308 0 6532 138260 -/+ buffers/cache: 358208 156100 Swap: 264144 63140 201004

Invoked 3 more times (ids 3, 4 and 5), to check the apps is not reusing memory it already owns:

total used free shared buffers cached Mem: 514308 503008 11300 0 6568 138260 -/+ buffers/cache: 358180 156128 Swap: 264144 63140 201004

OK, pushing the limits, so invoked 46 times more (ids 6 to 51):

total used free shared buffers cached Mem: 514308 504308 10000 0 7284 136336 -/+ buffers/cache: 360688 153620 Swap: 264144 63364 200780

Used swap and mem (after removing buffers and cache) numbers seem pretty stable, just mimimal increases in both, some KB reduction sometimes (other app releasing mem probably). By your rule, the machine should be crawling now due the 50 copies. Just the pixels are 50 * 2000 * 2000 * 3 = 600 * 10^6, more than the physical RAM.

(__) (oo) Moo Super Powers
/-------\/
/ | ||
* ||----||
~~ ~~

GSR

Sven Neumann wrote:

Gerhard Gaußling writes:

In batch processing one can select an action (i.e. gimp-script), a folder for loading the files for processing and one for saving them, and in which kind the naming is to be managed, and so on. [...]

I think this is something that can be developed completely independently as a GIMP plug-in. And sure, I am waiting for someone to write this for several years already.

That's pretty much what David's Batch Processor does, except that is uses a fixed gui to control a number of common ops, instead of requiring a script to perform general ops.

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

That is great.

I did not know that the GIMP could reuse tiles from one image to another. Actually, I didi not tought this was done even from a layer to another - that explains why adding new layers to large images goes so smoothly.

I am more than happy.

How does this memory usega behave when one apply a transform (scale down in this case), ont he image, or on a copy of it?

Because Mateusz wrote me that the disabling undo improved the performance of the operation.

Maybe it is just the beneffits f not having "X" allocated anymore, and therefore no more swaps after the scale down.

Regards,

JS ->

On Sunday 20 February 2005 11:43, GSR - FR wrote:

I assume there is Copy On Write, thus delaying real memory usage (and the bandwidth too) until the data changes. Lets see COW at work:
(...)