[selowitch]

Up until now, I've been pretty happy maintaining two directories for my website locally (/images/ and /thumbnails/). AppleScript has made the process even easier for batch-process through either Image Events or GraphicConverter.

But I was wondering if, in a PHP environment, it would make sense to store only the /images/ directory and have PHP generate the thumbnails on the fly through either GD or ImageMagick.

The trouble is, of course, that those server-side tools look pretty hard to use. Is it worth the extra effort?

[Meijin]

I've got a slightly different version of that scheme deployed on one site, which uses GD to resize a photo on upload and generate a thumbnail that's stored elsewhere. (It's a slower server that I have no control over and is prone to bog under moderate use, gets updated somewhat often but the user is not savvy enough to deal with resize on the fly.)

I get all of my dimensions in PHP and then just send them via command line to GD. Honestly, it took longer to find the actual location of GD on the server than it did to write the code and tweak it.

It's not too hard to do if you're even at a basic php level. However, you may want to explore some sort of cache option for those thumbnails if they're being done on the fly so you're not generating every thumbnail at runtime for every user and every visit.

[Millennium]

I wouldn't do this if I were you, to be honest. At the absolute least I wouldn't have them generated on the fly every time; scaling images is usually very processor-intensive and so you'll kill the site's performance.

Meijin's idea of using a caching system might work, though. Basically, associate every image with a thumbnail, just as you do now, but funnel the thumbnail image URLs through a script which has the "real" image passed into it. The script looks on disk for a thumbnail corresponding to the "real" image. If it finds that image, then it just serves it up. If it doesn't find the image, it tries to generate one and save it to the disk so it won't have to do that again. If it can't do that, then it throws a 404.

The idea behind this is that the script will only have to generate each thumbnail once. If you want a new thumbnail, just delete the existing thumbnail and the script will make a new one the next time someone tries to access the thumbnail for that image. If you have a script which uploads images, you could modify it to delete any thumbnail images which correspond to an image which has just been uploaded, which will automate that process for you.

[besson3c]

Is it possible to use GD to resize a thumbnail, and save this thumbnail to a directory? It's funny and convenient this thread exists, because I was just about to look into this myself.

[Meijin]

Originally Posted by besson3c

Is it possible to use GD to resize a thumbnail, and save this thumbnail to a directory? It's funny and convenient this thread exists, because I was just about to look into this myself.

I'm sure it is -- I said above I was using GD but it turns out I actually did use ImageMagick. Here's the syntax to convert a photo to a thumnail (or, rather, convert one image size to another size).

Code:
$imagemagickPath = "path/to/imgmagick" //(in my case this is /usr/X11R6/bin)

exec("convert -geometry {$target_width}x{$target_height} /path/to/source/{$filename} /path/to/target/{$filename}");

That has worked for me for over a year and it generates static thumbnails (with the filename stored in a DB) when I upload an image.

Not too tough at all.

[selowitch]

Fascinating.

I think for my purposes I'm persuaded that the best approach is to auto-generate the thumbnails when the images are first uploaded. But would that entail triggering some kind of server-side script? How does one do that?

Perhaps one could run a GD script when the page is loaded that generates thumbnails for those images that don't already have one?

BTW, a bit of tangent: I like to put the /images/ and /thumbnails/ directories on the same level, so that my code can infer the location of the both an image and its thumbnail if simply given the filename, like so:

Code:
$imagepath="/images/" . $filename . ".jpg";
$thumbnailpath="/thumbnails/" . $filename . ".jpg";

Man, did that ever save me a ton of work! :-) Especially in concert with getimgsize()!

Meijin, do you have to create cron job to execute your script periodically, or what?

[Meijin]

Originally Posted by selowitch

BTW, a bit of tangent: I like to put the /images/ and /thumbnails/ directories on the same level, so that my code can infer the location of the both an image and its thumbnail if simply given the filename, like so:

Code:
$imagepath="/images/" . $filename . ".jpg";
$thumbnailpath="/thumbnails/" . $filename . ".jpg";

Man, did that ever save me a ton of work! :-)

Meijin, do you have to create cron job to execute your script periodically, or what?

It's done at runtime as part of the validation of uploaded images. Basically, the process is:
1. Verify image is of an allowed type. (jpg, png, gif, etc.)
2. Verify image falls within allowed bounds. In some cases, if it doesn't, it's flat rejected. In other cases, it's scaled down (using imagemagick) to fit the bounds I've established.
3. Once verification is passed, the image is moved to the images/ directory.
4. As part of post-processing cleanup, the thumbnail is generated off of the above image and put in a thumbnails/ directory. (In this case, I also usually prepend -- so if my image is, say, powerbook.jpg, the script uses the above PHP exec command and generates tn_powerbook.jpg and puts it in the thumnails directory.
5. As appropriate, entries are made in the DB to note location, dimensions, etc. of the files.

It's all part of the same validating PHP page that accepts an uploaded image.

[registered_user]

I have a script that uses GD to pull it off. And I use multiviews to pass variables to the script. So I don't actually have an images directory, but rather images.php which handles the requests instead. All of my uploaded images actually reside in a directory called simply "i".

The script generates thumbnails based on request. That is, when I go to images/picture.jpg, it'll display picture.jpg, scaled to no wider than 300px. If I request images/fullsize/picture.jpg, it will just passthru to picture.jpg and serve up the original uploaded version of the file whatever its size. If I request images/thumbnail/picture.jpg, it will display a 75px square thumbnail of picture.jpg.

What the script does first is look in an image cache directory to determine if a thumbnail version of picture.jpg exists, if it exists, the script serves up that file via passthru(). If the thumbnail doesn't exist, then the script opens picture.jpg, scales it to the appropriate size and then saves it to the cache directory.

I suppose it could create the thumbs on upload, but this works well for me. I can also use it store all of my images out of the web root if I were so inclined.

[bluedog]

A lot of content management systems use a form for uploading an image that calls the creation of thumbnails. You could also simply have an administrative page with a call to search and compare if the thumbnails are available and create them as necessary. This could be done each time you upload a bunch of new images.

[mania]

I'll throw in a vote for ImageMagick (convert). its on most servers and is easy to call from php. this is especially useful if you are not the one uploading images but have say a client who is an admin to a shopping cart or something.

[inkhead]

I actually have a image asset management system that I wrote, The best on the fly thumbnailer is by far phpthumb. you can apply it directly in your code, have images resized, watermarked, rotated based on exif on the fly. If you need help PM me and I'll give you the run down. phpthumb takes advantage of GD/imagemagick, (GD being the better one for large image files) By far the best reason to use PHPThumb, is it's intelligent cache feature. It won't suck up CPU re-creating thumbnails, but it will re-thumb if the image changes ;-)

Best Solution Available
phpThumb() - The PHP thumbnail generator

[selowitch]

What I suppose I'm still unclear on is when does all of this occur? Does it happen every time an image is uploaded? If so, how is it triggered? Or, is it done occasionally—e.g., when you've uploaded several images and it occurs to you that they need to be thumbnailed. I don't yet have a clear picture of the process. Could it be done via a chron job?

[registered_user]

If your form is handled by a php script, you'd need something in that script to handle the images that are passed with the form data. The image is passed in its own $_FILES array. so $_FILES['image']['name'] is the name of the file sent from input name="image"

Your handling script would copy that file to the directory you want it to be in, and do any image manipulation you are after.

[tomrock]

This might serve as an example -- http://minigal.dk/

This is a little php script. You upload full-size images to a folder and the script presents them as a webpage. It's really pretty good.

Maybe you could look at their code and see how they build the thumbnails?

[selowitch]

Originally Posted by tomrock

Maybe you could look at their code and see how they build the thumbnails?

I'm sure I could. But I prefer to work backwards, starting with the question, "What is my workflow?" and then looking around for scripts whose short description matches (or comes close to matching) what I'm looking for.

Originally Posted by registered_user

If your form is handled by a php script, you'd need something in that script to handle the images that are passed with the form data. The image is passed in its own $_FILES array. so $_FILES['image']['name'] is the name of the file sent from input name="image"

Your handling script would copy that file to the directory you want it to be in, and do any image manipulation you are after.

Thank you. That's very helpful. I figured it was something like that.

In my case, I'd much rather upload/download my images using my favored FTP client (in this case, Transmit under Mac OS X) than through a HMTL/PHP form because it's faster and suits my work habits better. However, if I could figure out a way to generate a thumbnail of each image whenever it is uploaded or changed, that would be a real efficiency boon. That is my great white whale, so to speak.

In other words, if I can develop a way to trigger the thumbnail generation routine when I upload a file, that would be great. Perhaps if my webhost is running Mac OS X Server, I could create a folder action and attach it to my /images/ directory. Hmmmm....

Right now I do all of my thumbnail generation on the client side. I wrote this little AppleScript droplet that calls Image Events to resize the images and save them to my local /thumbnails/ directory that is in turn managed/synchronized via Transmit. It's not a bad workflow, but there are some problems.

It's somewhat tangential to this discussion, but I might as well mention that Image Events can't manipulate the resolution of an image (in dots per inch), and since these are for the web there's little point in allowing a resolution greater than 96dpi, if I understand correctly, since that's the max resolution of images displayed in a Windows web browser (for the Mac, it's 72dpi).

PHPThumb() sounds pretty cool and may be worth checking out.

[registered_user]

You could write a script called thumb.php.

So a request for thumb.php?file=mypic.jpg will serve up mypic.jpg in thumbnail form. You can take that a step further too. You can use multiviews so that the url would be thumb/mypic.jpg That way it appears cleaner and invisible to the user. You could do that with mod_rewrite too, but multiviews are easier.

thumb.php ideally would do a few things:
first, determine which file to serve.
second, determine if there is already a cached version of this thumbnail, and if there is, passthru() to that existing thumbnail.
third, save a newly generated thumbnail file to a cache directory.

Then, what you've got is a script that generates a thumbnail of an image the first time that image is requested and saves a copy of it. Each additional request will serve up the cached version.

That's more or less the system I use, and it seems to work well.

Getting it to work with each ftp transfer is probably not going to happen easily without a dedicated server that can watch a folder for new arrivals, but getting it to do the work the first time need arises is the next best thing, IMO. Alternately, perhaps you could set up a cron to check for new uploads on a certain schedule, but that seems like it would be running far more frequently than is necessary.