Some background info might be useful. Why are the images being stored in a database? Do you need to be able to access images farther back than the 50-100 images needed for animation? Are those 50-100 images always going to be the most recent ones? What's the expected number of views? I'd personally store the images in folders by day using some naming system involving timestamps, thus making it unnecessary to use a database to access the images.
Whether to store images in a database or not has been much talked about on the MySQL lists. The general consensus seems to be that you should store the image files in a filesystem since that's what a filesystem is designed for and store the html links to the images in a database since they're data for your program and that's what a database is for.
database systems would be faster than a file system at reading in image data for small images in quick succession. reason is that the db can read ahead in blocks, and will be working from maybe a couple of file system files. if you open/read/close 100 images from a file system, that's approx 100 seek operations on the disk, besides the 100 open/close OS overheads. And since you also store the image metadata (e.g. timestamp etc.) in the same db table, retrieving the right 100 images is a single sql statement. storing same images with timestamped directories/files or whatever concocted method, means that you have to write silly code just to get the right image filenames/files.
i think that all that the thread poster wanted was a method for displaying the images from the database through a webserver. i believe that "multi-part" html page will do that, you just keep printing the next jpeg. the exact method/code is described in the book "Programming Web graphics with Perl and GNU software".
the hardest line to type correctly is: stty erase ^H