Personally, as a web developer, I’ve come across a number of clients that seem interested in doing some sort of web-based photo sharing application like flickr, or imgur, or photobucket. These are all pretty popular services on the web that allow you to share your photos with friends, family, colleagues, etc… They seem to be extremely popular and there’s no doubt that it’s evident people love sharing their photos online. Just take a look at facebook; possibly the world’s largest online photo sharing application that claims to get over 100 million uploads per day from it’s now more than 800 million users. With cameras found standard in such personal devices as phones, notebook computers, desktop computers, various other hand-held devices, and even (and don’t ask me why) TVs it’s no wonder we find it easy to store lots of digital photos and inevitably share them with others.
So I had to think long and hard about how I’d build an application or service like this so that it made good use of photos and made them easier to share and more accessible. The first thing that came to mind was checking out all the features these other services already had to offer and how they put them to good use. flickr allows you to do stuff like geotagging where you can tell people where the photo was taken. I remember either facebook or some app I may have tried a long time ago being able to do this as well. Since I log into my facebook account maybe two or three times a year I couldn’t say for sure, but what I do know is that facebook certainly got one thing right and that was not taking their users’ demand in wanting to share photos with friends for granted. When you’re able to point out who is in your photo that makes the information just that much more valuable and apprises the application for making photos more useful and accessible. There’s also a search value in tagging. But it can be pretty boring for a user to have to sit there and manually enter in all the information about each photo so we can rely on things like Exif where embedded information about the photo can be extracted by computers. You can get such information as GPS coordinates of where the photo was taken, a time stamp of when the photo was taken, the camera make and model that the photo was taken with, whether not the flash went off when the photo was taken, and even various other things such as focal length, exposure time, shutter speeds, etc… You can learn a little more about the Exif specifications here. However, keep in mind that not all cameras provide this format and not all of them are equipped to provide all of the different parts in the Exif header. Newer phones like the iPhone 4 are GPS capable and can embed GPS data into your photos if the GPS is turned on. There are also many digital cameras that either come with GPS devices embedded or can be purchased separately. Some other features you might want your application to have to make the process of having the user input information about each photo easier is facial recognition. This doesn’t have to be so sophisticated that it can automatically detect faces found in other pictures and tell you who’s who, but it can be helpful to let the software detect if a face exists in the photo and highlight it so that the user can simply type in who each person is for tagging purposes.
There are also some potential uses that I’ve found for OCR (or Optical Character Recognition) in photo sharing. If you can manage to extract enough significant textual data from the image you might be able to make certain aspects of search easier to locate photos. This is probably not going to be easy given that what little time I did spend fooling around with various OCR software proved that it has many setbacks and is clearly in the very early stages of development. Mostly OCR has trouble detecting text if the font size changes through the image, if the text encounters large skewed angles or if the text is rotated so that its orientation is not top-to-bottom and left-to-right. It’s also difficult to detect hand-written text, or text surrounded by other images, logos, or with too much depth or noise. There’s also quite a challenge trying to detect text written in various languages that don’t use the Latin alphabet. If it’s not a scanned image coming straight from the page of a book using a single evenly-spaced sans-serif font, with a fixed font size of around 12-20pt it will prove rather difficult to get any decent results from the OCR software.
So to give you an idea of what some good features of a photo sharing application might look like I put together a small working demo. My example makes use of most of the features I’ve discussed here, but leaves much to be desired, of course.
You can see the working Photo Application Demo here.
Here is a sample photo with embedded Exif information including GPS to demonstrate.
Here is a sample photo that demonstrates the applications ability to utilize some OCR techniques.
A Note About User Experience
OK, so I wanted to make sure this demo illustrates some of the basic functionalities a user might expect in a photo sharing app. The first thing you’ll notice is that uploading large photos and especially a lot of them can be a boring thing to do over HTTP. That’s because HTTP is built on a request/response model. You have to send a request first and then you eventually get a response back. Now if your request happens to be a 10 MB photo or even worse a 250 MB video (or even worse you don’t have high-speed Internet or your ISP offers lousy upload speeds) well… that’s a long wait with no indication at all to the user as to what’s happening on the other end. What’s even worse is if the user is uploading a file they aren’t aware is too large for you server to accept that can be a lot of waiting around for nothing. So I used some javascript combined with a script I found online at phpfileuploader.com and with a few modifications for security and improved user experience I hacked up a somewhat better interface for the user to deal with uploading multiple photos.
One thing you don’t want is to prohibit the user from being able to do anything else while they’re uploading their photos. Pop-up windows are just annoying, in my opinion at least, and forcing the user to wait until the entire upload is done before they can do anything else in the window is even worse. So if you try out my demo you can see that it doesn’t prevent you from browsing other photos on your computer to select for upload even while it’s doing the uploading simultaneously. You can even cancel an upload mid-way or cancel all pending uploads at once. It will also alert you ahead of time if you’ve selected too many files at once or if your images are too large or of the wrong file type. However, not all of these features are entirely reliable for security reasons as the user can easily bypass them. But they are their to improve the user experience. All the real security work is actually done on the server side. Even if you were to rename foobar.exe on your computer to foobar.gif and managed to upload it the server will still detect that it is an incorrect MIME type and reject the upload. This can be done relying on PHP’s File Info extension where it can check the file’s MIME type from the server’s supplied Magic MIME file.
Now, keep in mind that tracking the progress of the upload is just half of the battle. There’s also the part about viewing your photos after you’re doing uploading them. In my demo I used a javascript library called easybox which is based on the lightbox framework, but it plays nice with jQuery and seems to work a lot more smoothly in my opinion. You can download easybox from Google code and try it yourself. On the top right hand side of my demo where you see your gallery you can click on any of the thumbnails and it will use easybox to nicely let you view all of the photos in your gallery in a slide-show fashion without ever having to leave the page. You can also, of course, easily get a permanent link to each of your photos to share with others from the list of recently uploaded files below that. Your session will expire after 30 minutes of inactivity, however, and you will no longer be able to delete those photos. If you have cookies disabled you won’t be able to see what you’ve uploaded, but your photos will remain on the server indefinitely.
A Note About Using Javascript or Flash
One thing I wanted to point out was that your applications should definitely work better with javascript or flash or even Java Applets or whatever client-side components you may want to use to improve the functionality and user experience of your application. However, you should also consider that if your applications can’t work at all (if even with a degraded user experience or a limited use of features) then you’re not degrading your web applications in a graceful manner. In my demo, for example, I made sure even though I’m using a lot of javascript and even some flash to make the upload process a lot more user-friendly you can still use the application even without the javascript or if you don’t have flash installed. You can test this yourself and I even tested it on the Links web browser (which is a completely text-based browser with no javascript capabilities) and I could still manage to uplaod my photos and download them just fine with zero problems. This isn’t always possible, or easy, for every application, but it’s definitely a good idea to at least put in the effort to gracefully degrade your applications so that they can be somewhat usable to browsers of lesser capabilities. I even managed to get it to work on my phone (a Samsung) which is a pretty horrible phone with an even more horrible browser, but hey having a bad user experience is still better than having no experience at all.
A Note About Links
So I wanted to emphasize a little on how the link structure of an App like this should work. One thing is you certainly want to be able to provide permanent links to the uplaoded photos so your users can share their photos with others. The link should be as short as possible. If your links are 500 characters long it’s probably not going to look that great when you paste them in an email or an IM window for a friend to take a quick look. However, facebook and flickr don’t seem to mind too much about how long the link is. I do have to point out, however, that they probably store billions of photos and my system would certainly not scale for them. With that said in my demo you’ll notice every photo gets a random five character alpha-numeric (case sensitive) link that is directly pointing from the application’s web root. This is the same system imgur uses for their gallery links as well. Except that I noticed a few deficiencies in their method. For one thing they don’t seem to care much about the extension you use to directly view the image. For example, if I upload an image to imgur I might get a link that looks something like http://imgur.com/abcde which would give me a web page with my photo and some information about it (much like you see in my demo) and the direct link to my photo would probably look something like http://imgur.com/abcde.jpg or whatever the file extension was. However, if I were to visit http://imgur.com/abcde.gif or even http://imgur.com/abcde.pngabc I would still be able to see my image. However, I can’t go to http://imgur.com/abcde.exe because that seems to give me an image stating the requested image was not found or has been deleted. Upon some investigation I noticed that their servers return the Content-Type header based on whatever the extension you supplied is as long as it starts with an extension they accept such as jpg/gif/png but it doesn’t matter if it’s proceeded by anything else. This is actually pretty bad, because the file still comes back with the same exact MIME type I uploaded it in. So clearly they aren’t providing the same image in various formats just conforming to some loosely thought-out rewrite rules. Basically I have similar features in my demo where the webserver (in my case Apache) uses rewrite rules and conditions to verify the requested URL and route the request to the proper PHP script and with a little magic you have access to all of your photos from the webroot even though the image files themselves aren’t even stored in the same physical directory as the webroot on my server. So far this demo has only been up for a couple of weeks from the date of this blog post and at around 1,000 uploads and 30,000 views it seems to be reasonably responsive enough that it proves scalable with a little work. I’m using GOCR for the Optical Character Recognition stuff, which is an open source tool developed under the GNU Public license and you can visit their website here to download it or to get more information if you’d like.
A Final Note About Photos
Well, that about covers what I wanted to say about sharing photos on the web and building applications that can do this nicely. Just keep in mind there is a lot to be done with photos that we are yet to uncover. So be prepared to make some good use of these features in building your own applications. I hope my demo gave you some ideas to work with. They are all feasible and not incredibly difficult to implement as you can see this brief demo only took me a few hours of work to put together and works rather well for it’s purposes. Sorry for the horrible interface though that’s one thing I didn’t have time to actually work on. Do let me know what your thoughts are on this subject and if you have any photo applications you’ve built or ideas you’d like to share.