The tech gurus behind the scenes at Scientific American have been working out kinks in our new network, and some of the issues relate to image size & storage. Thus, here's a quick post on file size for blogging.

Before I start, let me grab a test image:

The original file straight off the camera is huge: 19,000 KB. At median US broadband speeds, a user would wait over a minute to download. Too slow for a blog post. And the image is waaaaaayyy too large, anyway. At full resolution it's three to four times wider than most computer monitors.

Obviously I need to shrink the image.

Shrinking is more complex than it appears, because images can be reduced in several ways.

First, the physical dimensions can be altered. By how much? As an upper bound, consider the working width of the blog. Every blogger should know their column width, in pixels. This blog is 600, so when I wish to post an image in full glory I'll resize to that. Sometimes less, if the image is vertically composed or if I wish to embed it within text. Anything larger than column width will either run into the side bar or be auto-crunched in ways outside my control, depending on the blogging software.

Merely reducing dimensions doesn't get us nearly far enough, though. A 10 image post of images 600 pixels in width will take 10 seconds at US median download times, and that's still rather slow.

We can further shrink an image by compressing information within the file. Compression is basically a shortcut for eliminating redundant data. Our test image, for example, contains many yellow pixels. Rather than simply listing each pixel and its color, a compression algorithm might identify the pixel positions that share similar yellow values and code them together, saving the replication of writing "yellow" (or the digital equivalent thereof) over and over again. Thus, the underlying data matrix can be made smaller while the output image remains roughly the same.

Numerous methods are available for image compression, but most systems have settled on the JPG format, as it does a good job of retaining the visual quality of the image through some drastic changes in file size. In fact, JPG-compressed images can drop 80-90% of the underlying data before the aesthetics of the image begin to seriously degrade. Here's our test image at more severe levels of compression:

The jump from low to medium compression- that's high (12) to medium (6) quality, in Photoshop- provides a significant 4x gain in download time while only slightly affecting the quality of the image. But look at what happens thereafter. The lowest quality/highest compression setting only shaves a little download time compared to the medium quality, and the image looks terrible.

To answer the question in the title- How much should blog images be compressed?- I hold the answer is, a fair amount, but don't overdo it. Best to settle on an intermediate setting.

Thus, to prepare an image for blogging, I do the following:

  1. Resize to no greater than blog column width.
  2. Save as an intermediate compression (quality levels 6-8 in photoshop) JPG.

To pick a hypothetical example, let's say my webhost allows a scant 10MB of images. That's unreasonably small, but I digress. With 10MB, I will run out of space for my uncompressed, 600 pixel-width images after posting only 30. If I use intermediate compression, I'll be good for four times as many- 120 pictures- with scant effect to visual quality.

As a final note, one additional way to be polite to dial-up readers is to bifurcate images into 100-pixel thumbnails and larger files. The front page loads quickly, and users can decide at their leisure to view the large files that may take several minutes to download.