OTFG Step 8: Resizing Images

The next step in going off the grid to host my own photos was resizing my images for display. My initial import script downloaded just my original photos that I uploaded to Flickr. But when you upload a photo to Flickr, the service creates four (sometimes five) copies of the original image at different sizes. This way Flickr can show various thumbnails of images in different ways, and they can use a standard size to display a photo on its detail page. You can click the "All Sizes" button above any photo at Flickr to see all of the sizes available for that particular photo.

I needed to do something similar, and I'm not sure exactly how I want to display my photos yet. So I decided to use Flickr's default image sizes (for the most part), to give me some different sizes to play around with. I went with the following sizes:
  • Medium Thumbnail - 240 pixels max width or height. Flickr uses this size for their photostream pages.
  • Tiny Thumbnail - 100 pixels max width or height. Flickr uses this size for JavaScript syndication (Flickr Badges).
  • Square Thumbnail - 85 pixels square, cropped from the center of the original image. Flickr uses a 75 pixel square thumbnail on the member home page and in back/next links on photo detail pages.
Flickr has a nice naming convention for these different sizes. They use [FlickrID]_[Thumbnail code].jpg to denote the various sizes. So a square thumbnail in their system will have a name like, 359119647_4874f02815_s.jpg, and the same photo in a bit larger size would be 359119647_4874f02815_m.jpg. I went a similar route, but decided to separate the thumbnails from the original photos. By placing the thumbnails in a different root directory, I can stop search engines from indexing the copies with a well-crafted robots.txt file. That means any photo that is syndicated out through Google Images, Yahoo! Images, etc. will be the original photo I want to share.

And because the thumbnail URLs won't be thrown around in the wild, I decided to use a naming system that doesn't give any information about the file itself. I thought that if I could assemble a thumbnail name from limited information (just the PhotoID) that could minimize the amount of stuff I have to pull out of the db. But I don't want to expose PhotoIDs through the system—that could let someone look at photos that aren't meant for them by guessing its ID in a series. So I went with an MD5 Hash of the PhotoID, plus a string that's unique to my application. That should obscure my IDs to all but the most determined cryptographers.

Beyond the thumbnails, I also wanted to set a maximum photo size for the original photo. I'm not sure what the design will look like yet, but I know that I want a standard size to work with in designing the pages. That means I could a.) make sure to resize all photos to the maximum size before I upload it into the system, or b.) automatically resize any original that's larger than my max. I went with b to make my uploading life easier, and to scale down any large photos I might have uploaded to Flickr. (I tried to go with smaller sizes at Flickr, for the most part.) In this script, if an original photo is too large the original file is copied to [name]_o.jpg in the /photos directory, and then the resized photo is saved to the "original" filename: [name].jpg. I know this system isn't perfect, and I have a feeling this is going to cause problems down the road, but hey, what can you do? I think it'll work.

Here's the script I used to resize all of my images: resize-all-photos.php. And here's the unique information that you'll need to set at the top of the resizing script if you've been following along:
  • A PHOTO_MAX_WIDTH and PHOTO_MAX_HEIGHT for the maximum file size you want to display. (I went with 850 x 640.)
  • A PHOTO_QUALITY that will be used in PHP image functions. (I went with 95, but you can play with this up or down to change the filesizes and image quality.)
  • A SALT that's used for uniquely naming thumbnails on your system. (I used—wait a minute, you almost got me. This should be a string of 8-x characters that only you know about.)
  • The full path of the /photo directory set in the original import script, along with a new /thumbs directory at the root path of the site.
  • And, of course, your MySQL details.
  • The thumb sizes are hard-coded, but it should be fairly clear where to change them if you'd like different sizes.
With all of this set, I ran the script and generated a bunch of thumbnails. To get a sense of the sizes available and the file names/locations, check out this page. As I mentioned, this is very close to Flickr's standard sizes and I can always re-run this script with new sizes if I need something different for the final design.

And to help keep my eye on the goal, I set up a couple different pages with some ideas for displaying photos. Here's one that's very Flickrish, with the latest photo large, followed by smaller photos: onfocus photos preview. And here's another page with the latest photo up-front, and older photos as square thumbnails: onfocus photos preview 2. Getting closer!

Comments

Hey pb, still following along! Love the preview pages. I've thought about crafting my own, as well, just - well, like you said, to keep your eye on the goal.

Also wanted to put this here to alert people who might be following along (although maybe I should've put it on the FIRST post...). One trap I didn't notice until about step 3 of following along with you is that all your scripts assume the photos coming from Flickr are JPEGs. However, Flickr retains original file format - so some of my files were JPEGs, some were GIFs, and some were PNGs.

Here's why it's hard to detect: Flickr does not throw an error if you try to download a file that doesn't exist. What it does is send you an image that says 'Photo not available', but of the filetype of the original photo - so, for example, if I requested the JPEG-format original copy of a GIF picture in Flickr, Flickr will send me the 'Photo not available' pic with a mimetype of image/gif.

I've been remedying this while going along by doing checks anywhere you assume JPEG format, to check and make sure it's JPEG and not GIF or PNG. Anyone who stores multiple formats of photos on Flickr will need to do the same.

Looking forward to the next article!
Thanks, Phil, great catch. I have all JPEGs at Flickr so I didn't run into this. If Flickr is sending the correct filetype in the headers, then you should be able to continue to use file_get_contents() to snag the file, but check $http_response_header for the proper filetype and change the extension accordingly. Unfortunately, all of the image resizing stuff I've put together so far is JPEG only, so it'll require a bit more work to support more file types. But I don't think it'll be much more than a few lines here and there checking types and converting to RGB before cropping/rotating, etc.
Actually I would like to know how Flickr does resize their photos because it always looks better at smaller size. I read that it was some sharpening they did. It will be nice if you can have that up for your site as well so I can learn from it. :p
×

Search Results

No emoji found