cydewaze — 2012-12-28T16:42:33-05:00 — #1
I have a website that serves as my blog and a place to share my photos. Currently the blog is imported from an IPB forum blog that's hosted on the same machine, and the gallery is an old Gallery2 install.
The IPB forum is on the blink (database corrupted somehow) and it was a pain anyway because no one could reply to my blog posts unless they registered on the IPB forum. The Gallery is fine, but Gallery2 is old, and the new version doesn't play well with my existing website design.
I considered going Wordpress for both the blog and the photo gallery, but getting WP to work with my existing design is no more work (and a lot less fun) than making my own stuff from scratch. I've already written a blog for my wife's website, and it works quite well, so all I really need to do is make the photo gallery.
So this leads to my question(s).
First, I'll probably be resizing my pics to 1280x resolution locally, then uploading them. I'm going to have thumbnails in the gallery, but I think the 1280x size is too big for a "browse" size (something that someone would click "next" on and see the next pic in the series without waiting an hour). So I'm thinking about having the thumbnail size (150x-ish), the "browse" size (640x or 800x) then the full size.
The server will create the three sizes after upload, and I'll have things like the description and album name in a database, but I'm wondering whether to just store the different sizes in different folders, or identify them by filename.
Is there a best practice?
scallioxtx — 2012-12-28T18:00:39-05:00 — #2
What I always did (I have no use for image uploads at my current job) is accept the uploaded image and dub that the "parent" image. From that parent image the code could create all kinds of derived images (or "children" as I called them, not entirely apt but close enough). The main idea is that you store the information of the parent image in a table and when you need a child image you see if there is already a record of it in the database, and if there isn't, generate it. (pitfall: if the db says the image exists but it doesn't exist on disk you'll need to generate it anyway).
For the parent images I only stored the width, height and filename, but you can of course store what you like. For the child images I took the md5 of the parent ID concatenated with the filters applied (resize, colorize, black/white, etc) and use that as the directory name and then use the filename of the parent for the filename of the child and put it in that directory.
The advantages of this scheme are
- people won't be able to find images once they've got the URL of one by simply increasing the ID for example. Handy for when you want to upload some images but don't want to make them public yet.
- since you only generate images when needed you're not using disk space for images that are never requested
- at any point if you need more disk space you can savely remove all "child" images and their database records. They will be reconstructed when needed.
- if you ever want to add another size, like 640x480, just add it to your code and it will be generated when requested. No need to post-process all images uploaded so far, ever.
The main disadvantage is that generating images on the fly is slower than generating them when you upload them, but this is only on first request. I've found that this disadvantage does not outweigh the advantages. And if you do want that extra speed you can always just generate the "children" when you upload a new image and store them to disk. "Warming the cache", as they say.
cydewaze — 2012-12-28T20:34:21-05:00 — #3
Thanks Scallio. That's an option I hadn't considered (which is the point of this thread I guess!). I'll need to do some test coding and see how "slow" the method is given the platform I'll be using. I don't think disk space is a huge issue for me, because I have literally thousands of pics in my existing Gallery2 install, and I'm not even using half my 1GB space allowance. When I implement my new gallery, I'll likely be deleting at least a third of those, because I used to just upload the entire contents of my camera, so there are a lot of junk images there now.
It's still a great suggestion though, and I especially like the option to add additional pic resolutions later. In fact if generating the pics ends up being fast, I could even provide a list of many resolutions, then delete the "child" images when the session ends. Hmmmm...