Rogier Wolff wrote:
I wrote my own rotate 90 degrees program: The image was stored in blocks of 100x100 pixels. so 10k bytes of memory per block (my case was grayscale). Now to rotate the image, a row of the source and a column of blocks of the destination was swapped in. 70 blocks one way 100 blocks the other. So after swapping in 170 blocks of 10k (= 1.7Mb) we could rotate an entire set of 100 lines with the 1.7M working set! With 16Mb in my machine that didn't stop the swapping, but it speeded up the progress by a factor of 100 or something like that. Many "large image manipulation" programs would benefit from this same trick. With current memory sizes we should use blocks of something like 128x128 or even 256x256. Then we have 64k pixels per block, at 48 bits per pixel that comes to 384kbytes per block.
Photoshop, Gimp both use a tile based cache, for this very reason, but (AFAIK) they *also* handle the swapping explicitly. War story; I had a program that sat and thrashed (on a Sun 3), that was pan-scrolling a visualisation of a large 2D data structure of records. I simply altered the access of the record at (X,Y) to be via a macro that implemented the block model Rogier describes, and it behaved perfectly. BugBear -- You received this message because you are subscribed to the Google Groups "Hugin and other free panoramic software" group. A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/hugin-ptx
