That's the point: I need no alpha, layers or something. Just a
rectangular selection for crop, flip and a simple striping plugin
(which I wrote). And the swap file went to three times the size by
just loading the image, not even moving or clicking the mouse, zero
undo levels.

64 megs of ram is just for testing the behaviour. The machine that was
supposed to do this job was upgraded to 256 megs of ram. I didn't dare
to count the time spent there watching gimp load a 10 meg tiff file,
which caused gimp to grow the swap to about 1.7 gig, then when I tried
to crop it, grew the swap to 2.whatever gig (the file size limit on
ext2fs), then filled up the ram, then crashed. I guess it was at least
half an hour for all this. And it was with 0 undo levels, and 190 megs
tile cache size.

Kelly: no, I'm not asking gimp to not store the image decompressed, I
just want it to use a display buffer sized to the window size, not to
the image size. Of course, several copies of the image (in this case
105megs) will be used for layers, alpha, undo, whatever. However, when
I crop and I have zero levels of undo, the swap file size should not
grow! If I work on a rectangular selection, there should be no working
copy, just work on the current image.

The sad part is that the company that asked me to do this told me to
skip it 'cause it's not working. They reverted to using a
*cough*win*cough*dows program which loads and displays and flips and
crops in seconds (!) and they're striping the images manually because
it's faster than gimp. Ouch, that hurts... I'm going to ask them and
find out the hard/soft config of that machine.

Gimp is great: it has many complex features, but they work on small
images (compared to these which get to be meters of printing on a A3
printer). Do you guys know of any open-source program for linux that
does simple operations (rectangular select, crop, flip, and I'll write
the striping thing) on huge images? That would save the reputation of
Linux in front of those guys.


> On 20 Jul, somnorici  wrote:
> > I set the undo levels to zero and loaded an image. 9376 by 11488
> > pixels grayscale is 107,711,488 bytes. My display depth is 16
bits. It
> > didn't take long to link this with the swap file, which after
> > loading the image was 292,421,632 bytes, plus the 32 megs of tile
> > cache (it's on a 64 megs machine used for testing), it kinda
> > three times the size of the image.
>  The raw data are 105 MB without alphachannels, layers or something
>  else. GIMP may be more efficient with memory, but I don't think
>  it's such a big issue which would lead us to reconsider the memory
>  management before our 1.2 release. 64 MB of main memory won't make
>  you happy with that imagesizes anyway....
> -- 
> Servus,
>        Daniel

Reply via email to