{"id":21400,"date":"2016-07-27T13:15:52","date_gmt":"2016-07-27T13:15:52","guid":{"rendered":"http:\/\/a_one_color_image_is_worth_two_thousand_words"},"modified":"2025-02-23T15:00:46","modified_gmt":"2025-02-23T23:00:46","slug":"a_one_color_image_is_worth_two_thousand_words","status":"publish","type":"post","link":"https:\/\/cloudinary.com\/blog\/a_one_color_image_is_worth_two_thousand_words","title":{"rendered":"Compressing a Single-Color Image in Various Formats"},"content":{"rendered":"

In part one (One pixel is worth three thousand words)<\/a> of this turned-to-be-two-part blog post, I discussed one-pixel images and how well different image formats \u201ccompress\u201d 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\u2026).<\/p>\n

Seems that my fellow image compression enthusiasts were as excited as I am about this subject! This blog post sparked a fascinating Reddit discussion<\/a>, in which other formats like BMP<\/strong> and TIFF<\/strong> are considered, and a 141-byte one-pixel JPEG file was given (smaller than the 160-byte JPEG file that I thought was minimal).<\/p>\n

With that in mind, I\u2019m happy to introduce part two, where we\u2019ll look at single-color images<\/strong> and examine them in length. I hope you find it interesting and would love to hear your thoughts and insights!<\/p>\n

The most predictable image<\/h2>\n

As we saw in part one, single-pixel images are the worst-case scenario for image compression: they\u2019re all headers and overhead, and very little data. You can\u2019t really compress anything, since compression depends on predictability, and how are you supposed to predict one single pixel?<\/p>\n

In this second part of the blog post, we go to the other extreme: extremely predictable images<\/strong>.<\/p>\n

The most predictable image is a large rectangle in a single color. In other words, a scaled-up version of the one-pixel images I discussed in part one. An empty canvas, if you want. A blank sheet.<\/p>\n

Compression algorithms should be really good at compressing an image where every pixel is the same color. It\u2019s the best-case scenario, the ultimate in predictability \u2013 once you\u2019ve seen the first pixel, you\u2019ve seen them all.<\/p>\n

Let\u2019s take a single white pixel and scale it up to increasingly larger squares, and see how the various image formats perform. I wrote a little script to do just that. Here\u2019s the result:<\/p>\n\n\"Comparison\n<\/a>\n

Since we\u2019re looking at squares, the number of pixels is, well, the square of the number on the x-axis: as the width of the square goes from 1 to 5000 pixels, the size of the image goes from 1 pixel to 25 megapixels. So it\u2019s not surprising that some of the curves look like quadratic \u00a0functions. The uncompressed PBM<\/strong> format obviously has a file size that is (asymptotically) linear in the number of pixels (1 bit per pixel in this case). But JPEG<\/strong> and lossy WebP<\/strong> are also linear in the number of pixels (quadratic in the width of the square) \u2013 just with a better constant factor. In other words, they seem to have some inevitable cost per pixel. For JPEG, it looks like you need at least 2 bits per 8×8 macroblock.<\/p>\n

This means that JPEG and lossy WebP have a theoretical limit on the compression ratio<\/strong> you can achieve with them: you can\u2019t do better than 0.031 bits per pixel (for JPEG) or 0.014 bits per pixel (for lossy WebP).<\/p>\n

Most of the other formats do not seem to have such a limitation. They do not look like a quadratic curve in the above plot. Let\u2019s see what we have here.<\/p>\n