[caption id="attachment_17125" align="aligncenter" width="500"] Storing pretty pictures can prove problematic for many Web developers.[/caption] As Web applications grow in number and capability, storing large amounts of images can quickly become a problem. If you're a Web developer and need to store your client images, do you just keep them on the same server hosting your Website? What if you have several gigabytes worth of images that need to be processed in some way? Today, many developers are looking for an easy but cost-effective solution whereby images can be stored in the cloud and even processed automatically, thus taking a huge load off one’s own servers, freeing up resources to focus on building applications. With that in mind, let's look at a couple different cloud-based services for image storage and processing. At first glance, these services seem similar—but they’re actually very different. I’ll clear up the differences to help you decide.

The Offerings

Here are the two services we're comparing: • Cloudinary • Blitline (Note that, as we approached publication, I was informed of another interesting product: an open-source package that does much of what Cloudinary and Blitline do, except you have to install the software on your own servers. It's called ImageResizer. I encourage you to take a look at this software.)

The Criteria

Here are the criteria under consideration: • Storage: Where does the company store the images? Do they provide storage, or is that your responsibility? Note that providing your own storage isn't necessarily a bad thing, as we'll discuss when we look at Blitline. And if the company stores the images, where exactly does it store them, and is that storage redundant? • Upload capabilities: I didn’t expect to include this, but it turns out that not all the services provide the ability for you to upload images directly; instead, you have to upload them to your own storage area (accessible via the Web), and then pull them from that location. • Image manipulation: What image-manipulation features are available? We'll look for sizing, scaling, filters, and more. • Storage of manipulated images: Are the manipulated (e.g. resized, cropped, etc) images stored, or are they generated with each call? And how does this affect your storage requirements? • Cloud access: Are the images pushed to different cloud regions for scalability? For example, when you put data into Amazon S3, the data is stored in solid-state drives. You can make the data public, at which point you receive a URL for the item. However, Amazon also offers its Cloudfront technology as an option, wherein you can take S3 items and push them out to Cloudfront, making them available for rapid access across the planet. Do other vendors that offer storage also offer Cloudfront-like cloud services? • What API and Developer libraries are available? • Integration with existing platforms: Do the services provide plugins to existing platforms such as Wordpress, and, if so, how are easy are they to use? In other words, do you need to be a software developer to be able to use the service? • Age of company and financial backing: Both are quite young, having arrived in 2011. • Price: The pricing structure is quite different between these firms.

Cloudinary

Cloudinary lets you upload images to their servers and serve out manipulated versions of the images. When you manipulate an image, the result is stored on the servers. The idea is that you can create a manipulated image simply by including parameters inside the URL that specify what type of manipulation you want (such as a resize, a crop, and so on). The URL contains all the transformation requests right in it; the Cloudinary servers read that URL, and either find the image with that manipulation already stored in the servers, create the image if it doesn't exist, and serve it out. This makes it incredibly easy to use. You can upload images to their servers either from your computer or by specifying a URL. There are APIs for many languages and platforms: Ruby on Rails, PHP, Django, Node.js, Java, .NET,  and browser-side jQuery. With the help of the APIs, you can upload images from your own software applications. I created an app in node.js, and it was very easy to upload an image: I just made a call into the API's upload function, passing the location of the file on my server's hard drive, and up it went. I received a URL and other information about the image, which I passed onto my browser app. The image transformations include resize, cropping and fitting (if the resized image doesn't fit that dimension, you can pad it or stretch it in different ways), zooming, face detection, rounding corners, and dozens of other effects such as grayscale, oil paint, vignette, opacity effects, and adding borders and backgrounds. The pricing structure is as follows: A free account offers 500 MB storage for up to 50,000 images and 1 GB bandwidth. There’s a Basic account: $39 per month, 10 GB storage for up to 1 million images, 40 GB monthly bandwidth. That’s followed by Plus: $99 per month, 40 GB storage for up to 4 million images, 160 GB monthly bandwidth. The next tier is Advanced: $219 per month, 100 GB storage for up to 10 million images, 400 GB monthly bandwidth. Then there’s Enterprise: They'll put together a solution for you if you need something more than the Advanced. One issue I found with Cloudinary is that, when you create temporary images, they stick around. This is by design, but not necessarily the behavior you might want. Each time you retrieve an image using a different transformation, Cloudinary creates the image for you and stores it in your “area.” Lets say you have an app that lets users create and transform images. One user might try six or seven different transformations, for example, and finally find the one he or she wants. With each transformation, you create a URL to retrieve said transformation from Cloudinary. The company stores that transformation and makes it persistent—even if the user doesn't want that one anymore. Of course, you can code your app to go through and manually delete the ones that aren't needed. But it would be nice if there were a non-persistent transformation feature whereby an image isn’t automatically kept. When your user picks the image he or she wants, your app could flag that image as persistent, pushing it into storage. (In fact, I'm going to request this feature from Cloudinary.) Also, I'm not sure what's to stop somebody from creating a Webpage filled with ten thousand image tags, each with a URL for a slightly different transformation, and loading that page just once, thus filling up your account with ten thousand transformations, all with you having no idea that it even happened until you log into your dashboard and see the damage. The Cloudinary documentation is excellent, complete, clear to read, and visually appealing. However, it is a bit confusing at times to find your way around, because some of the information that seems to be general to the entire platform is buried inside the language-specific documentation. But other than that, I found it to be very good. When you sign up with Cloudinary, you get a dashboard where you can see all your images, including the transformed ones, and upload and delete the images from there. This means that, if you're not a software developer, but still want to use Cloudinary to host images from your blog or Website, you can do so quite easily. In terms of security, uploading to Cloudinary requires the inclusion of a key pair. Without the key pair, the upload will not be accepted. However, if you're creating a Web app and want your users to be able to upload files, you can do so by signing a request: the server-side of your app needs to create a signature and pass this signature to the browser, after which the signature can be used to upload the file. There's a jQuery library that helps with this aspect.

Blitline

Blitline takes a different approach from Cloudinary, which is why it's important to understand how these providers differ. Whereas Cloudinary hosts the images for you, Blitline does not offer storage. Instead, you provide them with your own storage, such as Amazon S3. Then you make a REST call to their servers, sending a JSON structure describing where to retrieve the starting image, and which transformations to perform on the image. The resulting image is then placed in your S3 storage area. Notice I said “where to get the starting image.” That means you need to first upload your image to some server where Blitline can access it, such as on Amazon S3. You then make a call through your software to the Blitline servers. That's another place where Blitline differs from Cloudinary: with the latter, you upload the image to its servers and request the transformation through a well-defined URL, which results in the image coming back down to the browser. That means you can put the URLs right in your website with the transformation embedded right in the URL. Blitline, on the other hand, takes a REST request, which includes a URL but is a programmatic approach where you pass your transformation request along with it. You can make the REST request from any language or platform of your choice, as long as you know how to construct such a request. For example, if you're using node.js, you create a JavaScript structure, fill it with the location of the starting image as well as the transformation information; then make call the http.request function, sending the information. You'll get back a JSON response with information about where you can find the resulting image. You then pass that URL to your client app, such as your app's Web browser page. Clearly, Blitline is more for programmers, while Cloudinary is for both programmers and less technical people. To help with your work, Blitline includes libraries for Ruby, Node, JavaScript, Java, and .NET. Blitline does not offer storage, which means you have to factor in your own S3 costs on top of the Blitline costs. Since Blitline doesn't actually store the images for you, the issue I mentioned with Cloudinary about storing every transformation subsequently goes away. You have more control over what you're storing. Blitline offers many of the same image manipulation, transformations, and filters as Cloudinary, except for the facial recognition and a handful of other features. The docs aren't great, but again, this is more for programmers. The text gives you exactly what you need to know: How to make the API request, what to pass it, and what you get back. When you sign up with an account, there's a “Quickstart” page that just shows you the code you need to use to get started. As a programmer, this is fine for me, as I like to see sample code. But people who aren't technically advanced might be a bit alarmed by it. (But then again, the product isn't really geared towards such people.) In short, Blitline is an online API for image processing. They expect it to be used by programmers who know how to make a REST call, and know how to store and retrieve images from Amazon S3. The free Developer account includes two hours of processing time; Standard costs $0.79 per hour of processing time. Standard + Imagga includes a third-party add-on with features such as smart cropping.

Conclusion

Both of these services perform well, offering APIs for different languages and platforms. But the two have very different architectures. Cloudinary is a complete solution for storing, managing, and manipulating images, with a very simple REST interface that allows you to transform your images right within a URL. You can embed this URL right in an HTML img tag or background-image style, along with the transformation information, leaving little work on your end. Cloudinary offers a fixed price per month for storage and bandwidth. Although Cloudinary has a complete programmatic API, making it useful for software developers, you don't need to use the API and can instead use its dashboard to create and manipulate the images you want to use on your blog or website. Blitline is a programmatic API and does not include storage. It is intended more for programmers and doesn't include a dashboard for non-programmers. You provide the Amazon S3 buckets or Azure storage; you put your starting image in your storage area, and then make a call to the Blitline API requesting the transformation. You pass the transformation request as a JSON structure along with the call. Blitline makes the transformation and pushes the resulting image back into your S3 bucket. Blitline charges for the time it takes to make the transformation. Bottom line: If you're not a programmer but a web designer or blogger, Blitline won't be of much use for you. If you are a developer, both work well. The pricing structure is different and you'll have to run through some calculations comparing Cloudinary's flat rate to Blitlines price per time of transformation. Blitline certainly has the potential to cost very little; but then again, Cloudinary has a free account if you're not doing many transformations and not storing many images.

Transformation Comparison Chart

Feature	Blitline	Cloudinary
Add Text	X	X
Combine Images vertically or horizontally	X
Auto level	X	X
Auto gamma	X
Auto enhance	X	X
Blur	X	X
Change background on transparent	X	X
Composite	X	X
Contrast	X	X
Contrast stretch channel	X
Crop	X	X
Delete color profile	X
De-skew	X
Set DPI	X
Despeckle	X
Draw ellipse	X
Reduce noise	X
Set gamma	X
Grayscale	X	X
Draw line	X
Median Filter	X
Change Brightness, Saturation, Hue	X	X
Normalize the contrast	X
Pad	X	X
Photographize	X
Pixelate	X	X
Qunatize	X
Draw rectangle	X
Resample	X
Resize	X
Resize to fill	X	X
Resize to fit	X	X
Rotate	X
Sepia	X
Sharpen	X
Smart trim	X
Unsharp mask	X	X
Vignette	X
Watermark	X
Advanced Face Detection		X
Smart cropping	Add on
Facial recognition		X
Format conversion	X	X
Negate		X
Black and White filter		X
Oil Paint effect		X
Pixelate only faces		X
Auto contrast		X
Vibrance filter		X
Change color channels		X
Screen filter		X
Multiply filter		X
Remove background		X
Opacity		X
Add border		X
PDF to raster images	X	X
Images to PDF	X
Screenshot of a website URL	X
SVG to bitmap	X
Package images into a ZIP file	X
Upload from your app's browser page	*	X
Load Facebook and Twitter  profile pictures		X
* Your app can upload directly to S3, and then process with Blitline, all from within the browser.