1 post tagged “image uploading”
Client-side image resizing
52 Clix expects to have 2 types of users: photo casualists (this is not a word) and photo enthusiasts. We love both groups and so we want to cater to both. This blog post discusses meeting the needs of the casualists (still not a word), who we expect to have little interest in resizing and touching up their photos before submitting to a Clixie. The casualist wants to drag the 8 megabyte+ image right from their memory card to our Web site.
52 Clix doesn't have nearly the bandwith or storage capacity as the big guys (jealous glare at Flickr) nor the money to afford such luxories (jealous glare at Warren Buffett), so in the interest of cost-savings, and to some degree the user experience, we implement client-side image processing via Thin File's Java applet Thin Image Upload. We hope bypassing high-res JPEG file uploads is one of those un-noticed, but appreciated features.
For the most part, Thin Image Upload works like a champ. Users can drag the image onto the target region in the applet or browse their hard drive via Java's horrendously ugly file browsing UI. The applet resizes the image on the user's machine and pushes it to your server. Not bad.
Where things start to fall apart for Thin Image Upload is in its resizing algorithm. You can specify a JPEG compression, like any graphics library; however, the sharpening is a bit overzealous, something akin to Photoshop's "Nearest Neighbor." We're talking Playstation 1 jaggies, folks. The ill-effects are worst in images that feature fine lines, such as bridge cables or your uncle's spiffy pin striped zoot suit. To be fair, Thin File is likely just using the built-in Java graphics algorithm.
But this post isn't about the product as much as it is about answering the question, "how do we satisfy our users' expectations with a known constraint?" With the pin striped zoot suit craze in full-effect, we can't ignore the problem. The solution we've come up with is a mixed bag of image resampling. We allow Thin File to handle the first resizing pass, which is an image dimension somewhat bigger than our final. We still save on bandwith and meet the user expectation of a fast site. Once the image has been transferred though, it's time for the GD library in PHP to take over and make the image a bit prettier. The GD library's resizing algorithm is similar to Photoshop's default "Bicubic," resulting in a smoother-looking image. Interestingly, because the first pass is so sharp, by applying the final, smoother resizing on it results in a nice level of sharpness. When shrinking an image you often want to increase the sharpness anyway to push out some of the details lost. Serendipity, baby! Does Vitale own a copyright on that phrase? We hope not.
There are some small tradeoffs with this approach. First, we're pushing more bits upstream across the Intertubes, from an average of 70k before to about 370k now. On 56k modems, that's about 70 seconds. Not optimal, but reasonable. Second, PHP is now being tasked to do some additional work. That said, the improvement in photo quality far outweighs those negligible negatives. View the difference in the image comparison below - click to see the orginal image before Vox blog resized it.
So what about our enthusiasts? You know, the people who agonize over the levels in their photo and a 2.1 versus 2.2 radius sharpening. For those folks, they simply upload their photos at the exact size we use on the site and so long as the resulting file is under 70k, no automated process will touch it. The enthusiast gets exacting precision and the casualist gets ease of use. Everyone wins. Well, we'll see who wins... check out this week's competitions.
User Upload Validation Woes
Thin File's ThinImage wasn't without some pains. It was incorrectly assumed that a call to the session from the PHP scripting language would get us our validated user's credentials. Not so. The Java running on the page is its own instance - essentially an unvalidated user. We're not sure how other Thin File clients get around this security exposure and the Thin File site, nor support, has any documentation on suggestions to prevent anyone from uploading through the applet.
We resorted to a time-limited token hand-off between the page and the applet. A flat file outside of our document root is written with a long, random file name. It contains the user's validation credentials. This file name is passed to the applet, whereby validation is confirmed and the upload is permitted. The token flat file is then destroyed.
This approach works and isn't any less secure than session hijacking. The downside is that user's now have an artificial time constraint on their upload. This becomes a problem only when a user hits the applet upload page, leaves his or her computer for 10 minutes and then returns to upload their photo. Thinking about this problem out loud makes us think a meta refresh tag of 10 minutes that bumps the user to their last visited page would be a good solution. See that? You just read how a feature is born!
Alternative image uploaders
SWFUpload
Pros:
* File size limit
* Multiple file uploading
* File queuing with start & stop upload buttons
* File type(s) limit, including filtering on file browsing
* Familiar, native OS file browsing dialog window
* Beautiful, XHTML-compliant degradation (if that sort of thing turns you on)
* Faster than Java applets
* Free
Cons: (all of these are Flash limitations)
* No client-side resizing
* No client-side manipulation (e.g. rotation)
* Authentication is a little kludgy (Flash cookie bug)
Aurigma
Pros:
* Many client-side manipulations (resize, rotate, watermarking and more)
* Displays preview image on file browsing
* File size limit
* File type(s) limit, including filtering on file browsing
* Multiple file uploading
* Multi-language support
* ZIP compression
* Folder uploading
* Upload resuming
* Nerdy features (load balancing and file pairing stuff)
Cons:
* Most expensive
* Slowest to load
* Ugly, clunky UI (we don't care what their Web site says)
* Facebook uses it (we kid, we kid)
