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. -- ** R.E.Wolff@xxxxxxxxxxxx ** 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@xxxxxxxxxxxxxxxxxxxxxx https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
