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. Thanks, -Oliver --- In gimp-developer@xxxxxxxxxxx, egger@xxxx wrote: > 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 equals > > 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
