Jesse Erlbaum <[EMAIL PROTECTED]> wrote:
This application will dynamically create and cache image thumbnails at
request time, among other things. The ultimate goal is a Perl-based
implementation approaching Amazon's image server:
http://aaugh.com/imageabuse.html
That's cool. My favorite features are the overlaying of icons and image
"tilting".
I'm looking for feedback in three areas:
1. Is there anything similar?
Here's the only similar mod_perl module I see on CPAN:
Apache::GD::Thumbnail
http://search.cpan.org/~isaac/Apache-GD-Thumbnail-0.03/Thumbnail.pm
As is, though, it's not flexible enough. It only lets you specify
"ThumbnailMaxSize" as the maximum "length or width (whichever is
larger)". So it can't give you an image that's constrained properly to
fit within a given *rectangle*, only a square. It also appears to lack
any caching :-(
Here's a PHP app with almost identical functionality goals:
http://www.evolt.org/article/Automated_Creation_of_Thumbnails_With_PHP/20/24498/
Though I'm not terribly fond of its URL-scheme -- too many squigglies!
2. Is this useful / what features would make it more useful to you?
Beyond simply downsizing, I like the ideas of adding pixel borders, drop
shadows and the like. These bells and whistles add a lot of polish.
Among the many thumbnailing modules I see on CPAN,
Image::Magick::Thumbnail::Fixed adds a unique and compelling feature I
hadn't thought of:
*** Fixed-size thumbnails!
http://search.cpan.org/~aroth/Image-Magick-Thumbnail-Fixed-0.04/Fixed.pm
It generates images of the *exact* dimensions you request, rather than
the largest (but inevitably different) size image that will fit *within*
the size you requested. This approach simplifies the use of the image
server a *lot* because the calling pages can then have completely
*static* height and width attributes on their image tags, which improves
their page-load times and avoids the "jumpy" HTML layouts you get when
you specify the height, just the width (or neither) without having to
add code that checks what size image you actually got *back* in response
to your request.
Since the fixed-size image has to be padded or filled up with "empty"
space, you do have to add some background-color support to your url
scheme (gifs and pngs could have this added space transparent, but jpegs
dont offer transparency. Of course white would probably be a likely
default and, although this module doesn't seem to do it, borders and
shadows and whatnot could still be added to the "inner image".
(Although you didn't ask) Image::Thumbnail looks like a handy backend
image manipulation interface -- it wraps ImageMagick, Imager *or* GD for
the heavy lifting -- now that's flexibility!
http://search.cpan.org/~lgoddard/Image-Thumbnail-0.62/lib/Image/Thumbnail.pm
Essentially, given a particular request's parameters and a source
directory containing high resolution images, images will be
manipulated and returned to the user. This will obviate the need for
laborious graphic production and re-production every time the
high-res versions change.
For example:
http://foo.com/images/bigimage.jpg <-- Returns high-res image
http://foo.com/images/640/480/bigimage.jpg <-- Returns 640x480
version of same image
Exact URL structure TBD.
*** Real flexible/extensible URL schemes would be important to me. The
pick-a-scheme-and-bake-it-in approach would surely come back to haunt
you (the PHP application above as well as Amazon's complex, bizarre URL
scheme both appear to suffer badly from Weird URL You Cant Change
Syndrome). While graphic designers I've worked with tend to prefer a
*file* naming convention with "named sizes" such as *_thumb.jpg or
*small_*.gif, we programmers lean more towards more explicit and
structured choices like PATH_INFO (/resizer/x-100/y-200/image.gif) or,
better yet, ?url=parameters that non-programmers wont want to use. So
while I think a simple, obvious, human-readable (probably path-based)
default scheme is definitely a Good Thing, building in hooks that allow
implementors to completely override the way URL's are translated into
image transformation paramters would go a long way, I'd think.
For instance, I'd like to be able to roll my own conf file and subclass
the thing so that in
%directory = (
"/foo_[\d+]/" => {
'/_thumb.gif$/ => { x=> 100, y=> 200},
'/icon_.+.png$/ => { x=> 32, y=> 32},
'/_hires.gif$/ => { x=> 1024, y=> 768, fixed=>1},
},
# but in:
"/bar/" => {
'/(\d+)/(\d+)/.+\.(gif|png|jpg)' => {
x => '$1',
y => '$2',
mime => 'png',
},
}
or something insanely configurable like that. But I don't want to see
all that in your Image::Transformenator, I want to be able to bake it up
and snap it in!
...When the request comes in the high-res
version and the cached thumbnail will be stat'd. If the thumbnail
does not exist or is older than the high-res version, a thumbnail
will be re-created.
If this is to be used for a high traffic site, I'd think that caching
would be best done by a squid proxy out in front of it, especially if
mod_perl is the target platform! That would simplify the code an aweful
lot -- less code means fewer bugs! Plus this lets people use it with
different back-end image storage (blobs in db's, remote http, ssh, ftp
files and so on that can't be stat'd) Or at least lingerd would be
called for, to free up the fewer, fatter mod_perl processes to serve
more requests to legions of slow client connections.
On the other hand if the target is to be ExecCGI *and* mod_perl, maybe
it makes sense to separate the package into two logical layers: one a
simpler, purely-dynamic server module, suitable for a mod_perl server
with an external caching solution. And the second layer could be a
stat-caching + on-the-fly-generating module that would be appropriate
for lower volume sites, shared-hosting servers where mod_perl is not
available, and the like. This would also let folks plug in alternate
hires-image image sources and caching mechanisms by re-implementing just
this level.
*** Pump-priming
In the high-volume case, A performance bottle-nect might occur (esp for
mod_perl production sites) when the server has to suddenly do a *lot* of
dynamic on-the-fly image manipulation work, like when the cache is
cleared/purged for instance. It would be nice if it had a "batch mode"
command-line script that you could feed, oh say, last month's apache
access log file... and tell the server to pre-perform all the
image-transformations that had been requested in the past? Assuming the
site has not been radically redesigned recently, That could easily be
most all the work it ever has to do :-)
3. What should it be called?
My thoughts about the name (in loose order of preference):
WWW::ImageServer
I like that. Simple, to the point. All the other WWW::* modules on
CPAN seem to be http clients, though...
Apache::ImageServer
Did you not plan to support a plain old ExecCGI mode?
CGI::Application::ImageServer
Works for me. WWW::ImageServer is less 4 me 2 type tho!
Any other suggestions? (I'm open to changing "ImageServer" to
something else.)
CGI::Image::Transformer? (Images in disguise)
HTTP::Request::URLBased::ImageManipulator?
Image::Server?
Server::Image::Dynamic?
Thumb::Nailer?
I know. I'm no help at all :-)
-dave
---------------------------------------------------------------------
Web Archive: http://www.mail-archive.com/[email protected]/
http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=2
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
