[Zope] Caching on-the-fly resized photos

[Ron Bickers]

> -----Original Message-----
> From: marc lindahl [mailto:marc@bowery.com]
> Sent: Saturday, October 27, 2001 1:26 AM

> What about something where the user can select levels of 'zoom',
> perhaps out
> of 10 or 20 possibilities?

Well, the default photo object provides 5 "zooms" as it is.  You could
define 10 or 20, but as you point out, that would indeed bloat the ZODB or
file system.

Do you think it's still a reasonable thing to require the developer to
preset display sizes, no matter how many and whether or not they're rendered
beforehand or on-the-fly?

> 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'.

Indeed, it is very expensive.  In fact, so expensive in some cases that I
hesitate to make it an option even with caching, but I can see how it may be
beneficial.

The biggest problem I see with using a RAM cache with rendered photos is
that many photos of a moderate size could eat a lot of RAM.  Take 50
different photos where three rendered sizes average 50k each.  Cache them
and you've eaten 7.5MB of RAM.  My personal site currently has 414 photos
with a couple more hundred on the way.  If someone went through them all at
a single display size, and you RAM cached that one size of each photo at
50k, that's an enormous belly filled with happy memories...nearly 21MB of
happy memories.

Obviously you would want to put a cap on the RAM cache size, but then you
greatly increase the occurrence of the expensive rendering and thus the
practical effectiveness of the cache.  Am I missing something?

> 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).

I was suggesting that instead of using a RAM cache at all, that the displays
be created on-the-fly and stored like they are now (in the ZODB or
ExtImage).  I could then add a timeout property for displays such that when
a photo is requested, if the timeout passed for a given display size, that
display size would be purged.  Would that cause too much write activity for
an undoable database?  If you set the timeout to a really large number, much
larger than a "normal" cache might be, I don't think it would purged less
often.  I think you'd still end up with only the most popular display sizes
taking up space.  That is the goal, right? ... having a large number of
possible display sizes without them eating ZODB/file system space?

Do you see any other problems with this idea?  I actually like the sound of
it, but I could be overlooking some issues.

> For somethings like a photo album, you have only one re-size, which is the
> thumbnail.

I would consider my site to be a photo album, and I have 5 displays + a
thumbnail for each photo.  Most people using the Photo product will likely
have the same since that's the default.

> 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...)

I don't understand what mean.  Can you clarify?

_______________________

Ron Bickers
Logic Etc, Inc.