[Zope] Caching on-the-fly resized photos (was: Photo product: how to recreate thumbnails withImagemagick)

[marc lindahl]

> From: "Ron Bickers" <rbickers-dated-1004726577.71eff0@logicetc.com>
> 
> Can you provide an example application where this might be useful?

What about something where the user can select levels of 'zoom', perhaps out
of 10 or 20 possibilities?  If there are lots and lots of images on the
site, then the probability is that few of them will have all zoom levels
used.  But it also means that if all the zooms are stored with in ZODB
you'll get some nice bloat, or if they're in the external fs, you have a big
mess that someone has to back up.  So it makes sense to generate them on the
fly, and cache them so that popular ones are re-used, cutting down CPU
processing.

> 
> Also, how would you propose caching on-the-fly photos?

I wish I knew!  I'm trying to figure that out, but there's little
documentation on the RAM Cache manager or howto's or anything...

> 
> As stated in the RAM Cache documentation:
> 
> "Although Zope does not prevent you from doing so, it generally does not
> make sense to associate an image or a file object with a RAM cache manager.
> It will not cache the image or file data, since the data is already
> available in RAM. However, another kind of cache manager, an accelerated
> HTTP cache manager, is available and is suitable for images and file
> objects."

They're referring to Image, which is of course computation-free.  They do
suggest that it be used for something with 'expensive' computation, like a
database lookup.  For many applications, using IM or something for resizing
or munging an image would qualify as 'expensive'.

> 
> So it seems it wouldn't make sense to use a RAM cache with the generated
> Photo displays, and the accelerated cache is for setting headers for
> browsers and proxies, etc. to cache.  A RAM cache might be useful for
> on-the-fly photo caching, but wouldn't that quickly eat up memory?  I
> suppose I could store them just like the other display sizes and associate a
> timeout with them.  I'm not sure if that would be sufficient or not.

I was thinking that you would have one RAM Cache for the site, not one for
each image.  So you can control the overall amount of memory.  And, it does
what a cache is supposed to, which is save the most amount of repetitive
re-computation of the same thing (that is, the most popular image sizes).


> Much of this might depend on the application.  Should there be infinite size
> options for the user such that you could end up caching dozens or hundreds
> of display sizes for a given photo?

For somethings like a photo album, you have only one re-size, which is the
thumbnail.  Or maybe two, if you want a view that's 100% screensize or
something.  But the 'zoom' example above is a useful one for multiple
resizing.  In any case, cached or stored, will benefit from limiting the
user's options.  Because, this provides the opportunity for overlap among
multiple users, which benefits any type of caching (after all, storing the
thumbs is still caching...)