Same thing in a different view: I was suposed to write a plugin for
gimp that would do some simple stuff to huge images. They want to load
the image, crop it, sometimes flip it, then select an area and stripe
it (draw white lines at a 45 degree angle and one inch width). The
images are black and white, tiff format, load as grayscale.
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.
This takes me to the conclusion that gimp kindly allocates the memory
for storing the image after extracting it from the file, and the whole
image used for displaying, instead of only 3-7% which is actually used
for an image so big. Now this is a serious thing, and I'll have to
start digging the source to fix it... Is there anyone else
aware/working on this issue?
--- In [EMAIL PROTECTED], David Odin <[EMAIL PROTECTED]> wrote:
> I'm using The Gimp 1.1.8 and since you'll going to a feature
> I guess it's time for reporting bugs.
> Strictly speaking, it's not really a bug but here it is :
> I start The Gimp,
> Create a New image 256x256,
> Stroke a few (like 10 or 20) lines with the default brush with
> pencil tool,
> Close the Image
> Quit the Gimp
> For this very small session, the report says that 58 Megabytes