[Zope] Caching on-the-fly resized photos

[Robert Rottermann]

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.

Robert
----- Original Message -----
From: "Ron Bickers" <rbickers-dated-1004769126.c039d8@logicetc.com>
To: "marc lindahl" <marc@bowery.com>
Cc: "Zope listserv" <zope@zope.org>
Sent: Saturday, October 27, 2001 8:32 AM
Subject: RE: [Zope] Caching on-the-fly resized photos


> > -----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.
>
>
> _______________________________________________
> Zope maillist  -  Zope@zope.org
> http://lists.zope.org/mailman/listinfo/zope
> **   No cross posts or HTML encoding!  **
> (Related lists -
>  http://lists.zope.org/mailman/listinfo/zope-announce
>  http://lists.zope.org/mailman/listinfo/zope-dev )
>