[Zope] Caching on-the-fly resized photos
Sat, 27 Oct 2001 11:08:21 +0200
I am using Photo in a product which lets the user lump together text an
photos to create a story with pictures.
I have no displays created automatically. However the user can define a size
of the picture she wants to use. From this I then create a display.
Since the user will check here "story" while working on it the displays are
created at a very early state in the game where waiting is tolerable.
The idea of timing out displays is appealing.
----- Original Message -----
From: "Ron Bickers" <firstname.lastname@example.org>
To: "marc lindahl" <email@example.com>
Cc: "Zope listserv" <firstname.lastname@example.org>
Sent: Saturday, October 27, 2001 8:32 AM
Subject: RE: [Zope] Caching on-the-fly resized photos
> > -----Original Message-----
> > From: marc lindahl [mailto:email@example.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
> beforehand or on-the-fly?
> > They're referring to Image, which is of course computation-free. They
> > suggest that it be used for something with 'expensive' computation, like
> > 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
> 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
> 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
> > 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
> I was suggesting that instead of using a RAM cache at all, that the
> 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
> 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
> an undoable database? If you set the timeout to a really large number,
> 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
> 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
> it, but I could be overlooking some issues.
> > For somethings like a photo album, you have only one re-size, which is
> > 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
> > multiple users, which benefits any type of caching (after all, storing
> > thumbs is still caching...)
> I don't understand what mean. Can you clarify?
> Ron Bickers
> Logic Etc, Inc.
> Zope maillist - Zope@zope.org
> ** No cross posts or HTML encoding! **
> (Related lists -
> http://lists.zope.org/mailman/listinfo/zope-dev )