Are there standard patterns for implementing a class to dynamically load images?

I've been tasked with creating an application that works with thousands of images, far too many to load into RAM all at once. I guess it's somewhat analogous to a photo viewer like Picassa, in that at any given moment the application needs the pixel data from only a handful of the total cataloged images. The application must also handle extremely large images, where only some small subset of the pixel data would actually be required at any given time for image analysis or display, which, I suppose, is somewhat analogous to Google Earth. In short, the application must dynamically load only the portion of the pixel data that is actually required at any given time.

Having dealt only with static image loading typical of image libraries like OpenCV, CImg, or Magick++, I'm at a bit of a loss how I might best approach th开发者_JS百科e problem. So my question is: are there any standard design patterns for this requirement, or approaches to solving this (or a similar) problem?

BTW, for small images, I realize that I could simply delay loading of the image until it is needed, but there are two key problems that spring to mind with that approach. (1) This doesn't solve the large image problem. (2) Since unloading the image immediately after it is used could be inefficient, I would need some type of memory management handler in the application that only unloads images when new images are loaded and some memory threshold has been passed. Clearly a similar memory management issue remains for portions of a larger image loaded into memory. I will plainly admit that such a tool is beyond my knowledge and experience, so if that is the prevailing answer to this question, then I have a supplemental question. Could anyone recommended some basic tutorials on memory management?

Thank you for the help!

UPDATE: For those who are curious, I thought I'd share the approach I took. The image class I created lazy loads the image data. To solve the problem with loading thousands of images, I created a class that would keep track of the file handles (Windows has a limit - see _getmaxstdio), and the amount of image memory that was loaded, unloading as necessary. To handle very large images, I used the VXL image library as a back-end, which is able to load a subsection of a large image. Granted this isn't so efficient for some images (compressed images especially), but since I'm mostly working with tiled TIFF images, it works very well.

If the larger images are really large, such that do not fit onto screen, then it may be reasonable to split them into smaller pieces.

If you have usually to display the images reduced (zoomed out) then you can ease your work by creating and storing the reduced versions of larger images. The whole cascade of reduced images with sides x 0.707, x 0.5 etc takes maximally as lot of storage as original image.

For lazy unloading you can load images (or fragments, or reduced versions) and remember the time when these were latest displayed and as lot of memory they take. Once you hit threshold but need to load more images you can unload starting from oldest to free up space.

The first requirement seems pretty easy to meet. Just create a class that does lazy loading - meaning it only loads its data when it needs it.

The second requirement WOULD be easy if you were working with any kind of data that can be processed by offset. Most image formats use compression though so unless you want to limit yourself to those that do not, you're going to have your work cut out for you. An easier alternative might be to split the larger images into smaller ones and only load those pieces that are visible/being processed.

Part 2 - few image formats support loading a section of the image efficently

You are probably going to have to pre-process the images, reading them and splitting them into tiles in individual files (or a database).