Hi,
I'm trying to touch up the result of a panorama shot I took. This
takes quite long, mostly because the image is too big to fit into
memory.
I would like to suggest a way of storing the image data in memory in
such a way that it doesn't take so much memory. Or at least, it
doesn't require so much memory to be presently paged in.
Currently images are commonly stored as an array of rows of pixels.
With an image width of more than 1400 pixels, if I need to access a
vertical line of pixels, this will touch a different machine memory
page for every single line. Thus to access say 100 pixels, 400 kbytes
of core memory needs to be touched (from swap if memory is tight).
First, a page on a machine is usually about 4k. So the basic units
might be 4k. On the other hand, having the units be say 12k doesn't
cost much in terms of IO time, but makes things in binary fit a lot
easier.
So, instead of storing images in an array of rows of pixels, we can
store an image as an array of blocks. If a block is 64x64 pixels, with
24bit data, the block takes 12k of memory. Now, touching 100 vertical
pixels requires only two blocks of 12k to be in memory. This is a big
improvement.
Next, if we want to display an image that is say 5000x12000, my screen
has only one or two megapixels. So scanning all 60 megapixels to
display this is a waste of CPU time and memory.
To improve this, several scaled down versions (say by a factor of two
each time) can be kept. Thus of my 5000x12000 image, a 2500x6000,
1250x3000, and a 625x1500 version should be kept. To display up to 625
vertical pixels of my full image, should use the last version. This
means that less than 3 megabytes of memory needs to be touched to
display my image. On a reasonable computer this is unnoticably fast.
As each scaled down version uses 4x less memory, they cost little to
build and to maintain.
Oh. If I zoom into a 100x100 area of my big (5000x12000) image, the
old way of storing images would require 100 or 200 pages of image
memory to be present in core. My suggestion only 2 or 4.
If all plugins and internal image manipulation functions are "aware"
of the old way of storing images, then I'm afraid that this is a major
programming undertaking. If however, everybody accesses the image
through accessfunctions (getpixel, putpixel?) then things are a whole
lot easier.
Once you start manipulating images, of course, my suggestion makes
things a bit slower. However, I seem to be waiting a lot for my drive
instead of "doing what humans do best", so I think this would mean a
speedup on the whole. But of course, if things easily fit into memory
it might slow things down a bit. So possibly a runtime switch between
the storage methods is desirable.
Roger.
--
** [EMAIL PROTECTED] ** http://www.BitWizard.nl/ ** +31-15-2600998 **
** Delftechpark 26 2628 XH Delft, The Netherlands. KVK: 27239233 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
Q: It doesn't work. A: Look buddy, doesn't work is an ambiguous statement.
Does it sit on the couch all day? Is it unemployed? Please be specific!
Define 'it' and what it isn't doing. --------- Adapted from lxrbot FAQ
_______________________________________________
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
