Cloudinary Blog

Every picture has a story to tell. But the story it tells can change when you change the color tone, saturation, contrast, or other elements of a photo.

A few years ago, post-processing a digital image generally required a high level of skill and expensive software such as PhotoShop. But in recent years, popular photo sharing apps such as Instagram, Flickr, and Snapchat started offering built-in filters. Professionals take advantage of filters to make subtle corrections or adjustments. Casual users often apply more prominent filters that add their own unique touch or just make their images more fun.

Nowadays, developers everywhere are introduced to an application development trend called serverless computing. The trend isn’t new but rather an evolution culminating from a number of development methodologies, including service-oriented architecture (SOA), distributed cloud computing, Platform-as-a-service (PaaS) and Containers/Microservices. A key defining element of serverless computing is the serverless application’s logic that combines custom-developed code and 3rd-party service functionality. 

And so the song goes, well, more or less.

There really are an abundance of content delivery networks (CDNs) out there; and a time and a place in which each of those CDN services could win the race for fastest, most reliable, or best fit for for your resources. But somehow, you have to choose one, right?

You know that moment when you click a video link on your phone while on your way to grab a coffee from the office kitchen, but then you get that annoying buffering icon, and just give up? That video might have been interesting, maybe even valuable, but it’s just not worth your time.

“Responsive.” Where did that term come from, anyways?

In his sea-changing essay, Responsive Web Design, Ethan Marcotte explained:

Recently, an emergent discipline called “responsive architecture” has begun asking how physical spaces can respond to the presence of people passing through them. Through a combination of embedded robotics and tensile materials, architects are experimenting with art installations and wall structures that bend, flex, and expand as crowds approach them. … rather than creating immutable, unchanging spaces … inhabitant and structure can—and should—mutually influence each other.

One of the main optimization challenges for website and mobile developers is how to display sufficiently high quality images to their visitors while minimizing the image file size. A smaller image file size can lead to faster load times, reduced bandwidth costs and an improved user experience. The problem is that reducing the file size too much may lead to a lower image quality and could harm visitor satisfaction. Delivering an optimized image with just the right balance between size and quality can be quite tricky.

There are two different kinds of JPEG images: progressive JPEGs and non-progressive JPEGs. These categories have nothing to do with the JPEGs’ political beliefs. They’re all about the order in which they’ve been encoded.

Note: this article was originally published in Smashing Magazine.

Four years ago, Jason Grigsby asked a surprisingly difficult question: How do you pick responsive images breakpoints? A year later, he had an answer: ideally, we’d set responsive image performance budgets to achieve “sensible jumps in file size”. Cloudinary built a tool that implemented this idea, and the response from the community was universal: “Great! Now – what else can it do?” Today, we have an answer: art direction!

In the conclusion of this three-part interview the Jason Grigsby, we examine what the future may hold for images on the web. Previously: Part 1, Part 2.

EP: I want to go back to the idea that we started with, that images are fundamentally complicated; that they’ll always present us with problems. What do you think we are going to be working on and talking about in five-to-10 years with regard to images?

In part 1 of this interview, Jason Grigsby and I discussed how the industry came to understand the responsive image problem. Here, in part 2, we discuss today’s solutions — taking a particularly deep dive into the puzzle of “responsive image breakpoints.”

This is a guest post by Nicolas Hoizey, co-founder of Clever Age and creator of the Jekyll Cloudinary plugin. Nicolas’ plugin leverages Cloudinary’s image storage, optimization, resizing, and delivery infrastructures to automate responsive images in Jekyll-generated static sites. We think it’s the bee’s knees, and invited Nicolas to write a bit about the process and motivation behind it. Without further ado, here’s Nicolas.

Even though websites have changed dramatically over the years – from simple text-based pages to advanced in-browser apps full of images and videos – the underlying HTTP protocol really hasn’t changed - until recently, with the approval of the HTTP/2 protocol by the IETF. Today Cloudinary is proud to announce, as part of a CDN infrastructure upgrade, general availability of HTTP/2 support in our image and video management solution. This will help you optimize the user experience on your app or website even more.

Once upon a time, in long forgotten browser versions, getting a video into a website required creating and embedding Flash resources. But these days, all modern browsers support HTML5, including the HTML5 <video> tag, which means you’ve got a built-in video player that anyone can use.

I'll start by giving it to you straight:

As part of the recent "auto–everything" launch, we introduced two new transformation parameters – dpr_auto and w_auto, which pair the DPR and Width Client Hints with Cloudinary’s existing image resizing and delivery infrastructure, in order to serve up simple, automatic responsive images.

One of the most important things to know about compressing image files is that a smaller file size comes at the cost of a lower image quality. How much lower, and whether low enough to make a difference visually, depends on the image. Compression can be very effective at reducing the size of the image, and besides lowering the costs of storage space and bandwidth, a reduced image size goes a long way to retaining your users’ attention with faster, smaller downloads.

The Rolling Stones claim, “You can’t always get what you want”.

And when your application needs to crop hundreds or thousands of images to specific sizes within a strictly defined UI design, that frustrating Rolling Stones phrase may be ringing in your ears.

But maybe it doesn’t have to.

In part one (One pixel is worth three thousand words) of this turned-to-be-two-part blog post, I discussed one-pixel images and how well different image formats “compress” these images. I was surprised how much there is to be said about the matter. This was supposed to be a short blog post, describing one-pixel images and how they compress, and instead it became a glorious monster (and also a two part blog post…).

A couple of months ago while taking a break from implementing cool new features like q_auto and g_auto, I was joking in our team chat about how well various image formats “compress” one-pixel images. In response, Orly — who runs the blog — asked me if I’d write a post about single-pixel images. I said: "Sure, why not. But it will be a very short blog post. After all, there’s not much you can say about a single pixel."

Every image is unique and every one of your website visitors is different. In a perfect world, we'd like to adapt each image individually to be "just right" for every user. With "just right" being perfectly cropped, using responsive dimensions, correct encoding settings and optimal quality with the best image format.

As a developer, you want to allow your users to download multiple files in a single click. An easy way to download multiple files and share them is to generate a ZIP file. When images are involved, you may also want to normalize the original images before including them in the ZIP file, by scaling them down to the same maximum resolution or converting them to the same format.

If you make a copy of a copy of a copy, the quality will deteriorate with every ‘generation’. This problem is called ‘generation loss’. It is not difficult to understand why this happens with actual copier machines. Scanning and printing are not perfect, being based on noisy sensors and physical paper and ink, and the resulting noise will tend to accumulate.

It's great to have the capability to manipulate images on the fly by using dynamic URLs to customize the images to fit the graphic design of your site or mobile application. However, what if you want to manipulate an image depending on a specific image characteristic (like its width or aspect ratio) or its contents (does it contain a face?). What you need is a way to apply a transformation to an image only if a specific condition is met. Take for example a situation where you have allocated space on your page for a user uploaded image with a width and height of 200 pixels. Furthermore, if the image contains a face you would like to zoom in and focus on the face itself, otherwise you would like to fit the entire image into the available space: