Image Optimization, Part 3: Four Steps to File Size Reduction

Blog
About

Site Search:

Image Optimization, Part 3: Four Steps to File Size Reduction

November 14, 2008 at 8:37 am by Stoyan Stefanov | In Development, Performance | 26 Comments

Stoyan Stefanov. About the Author: Stoyan Stefanov is a Yahoo! web developer working for the Exceptional Performance team and leading the development of the YSlow performance tool. He also an open-source contributor, conference speaker and technical writer: his latest book is called Object-Oriented JavaScript.

This is part 3 in an ongoing series. You can read the other parts here:

This post is about some common tools you can use to reduce the file size of your images. The idea is to be able to just take the images your designer has created and instead of using them “as is”, go ahead and tidy them up in short time and no effort, without even looking at them.

The good news is that this process is:

lossless – you strip bytes, hence you lose some information, but not the pixel data and the resulting image looks exactly the same as the source with no quality loss
uses free tools – all the tools we mention here are free and open-source, and work on both Windows and Unix
automated – since these are command line tools, they are easy to script and automate; one example of such automation is the smush.it tool

Step 1: Crush PNG

PNGs store information in so-called “chunks” and not all of those chunks are required for the display of the image. In fact most of them are not. You can safely use a tool such as pngcrush and strip all the unneeded chunks. For example:

> pngcrush -rem alla -brute -reduce src.png dest.png

Let’s take a look at the options of this command:

src.png is the source image, dest.png is the destination (result) image
-rem alla means remove all chunks but keeps the one for transparency
-reduce tries to reduce the number of colors in the palette if this is possible
-brute tries over a hundred different methods for optimization in addition to the default 10. It’s slower and most of the times doesn’t improve much. But if you’re doing this process “offline”, one or two more seconds are not important since there’s a chance if a filesize win. Remove this option in performance-sensitive scenarios.

Running this command on the PNGs found on Alexa’s top 10 sites gives us an average file size reduction of 16.05%. This means you can easily strip weight off your PNG images, save bandwidth and disk space and improve load times, without sacrificing quality and without even touching a single line of application code.

PNGcrush is only one of the available tools for this sort of optimizations. Other tools you can take a look at include:

Now that we’ve got a pretty good PNG solution, let’s see if we can do the same for the other image types.

Step 2: Strip JPG Metadata

JPEGs files contain meta data such as:

comments
application-specific (think Photoshop) meta data
EXIF information such as camera information, date the photo was taken and even thumbnails of the actual image or audio!

This meta data is not required for the display of the image and can safely be stripped with no pixel quality loss. As discussed previously, JPEG is a lossy format, which means you lose quality every time you save. But luckily there are some operations that are lossless. Such operations include cropping a part of the image, rotation and the personal favorite – copying metadata. One tool that allows you to do these is called jpegtran.

Here’s a command to copy the source image, optimize it and don’t carry over any metadata in the new copy:

> jpegtran -copy none -optimize src.jpg dest.jpg

Note that depending on the version you have, you might need to use the syntax ending with src.jpg > dest.jpg

The -optimize option will cause jpegtran to optimize the Huffman tables and improve compression.

Running this command on Alexa top 10 sites resulted in average savings of 11.85%.

You may be able to further improve image size by using jpegtran’s -progressive option. It produces JPEGs that load progressively in the browser, starting from a lower quality version of the image and improving as new image information arrives.

Important note on stripping meta information: do it only for images that you own, because when jpegtan strips all the meta, it also strips any copyright information contained in the image file.

Step 3: GIF to PNG

What’s the best way to improve a GIF? Convert it to a PNG. As funny as it may sound, it’s true. Most of the time you get a smaller file size from a PNG and the same quality and browser support, as we discussed in a previous article. Note that PNG will not always be smaller, but most of the time it will be, so it’s worth checking after the conversion and keeping the smaller of the two files.

In order to automatically change your GIFs, you can use ImageMagick’s convert:

> convert image.gif image.png

If you want to force PNG8 format you can use:

> convert image.gif PNG8:image.png

This is probably not necessary, since GIFs will most likely be converted to a PNG8 anyway because ImageMagick picks the appropriate format based on the number of colors.

Once you’ve converted the GIF to a PNG, don’t forget to still crush the PNG result (as shown in step 1).

If the top 10 sites switch all their GIFs for PNGs (except those that don’t yield a smaller file size), on average, this will result in 20.42% file size reduction. The only inconvenience here is that you also need to write a search/replace script to find all the references to the GIF files and change them to the new PNG versions.

Step 4: Optimize GIF animations

Now that all GIFs are PNGs, PNGs are crushed and so are the JPEGs, what do we have left? GIF animations. One tool that can help you with those guys is called GIFsicle. Since the animations consist of frames and some parts of the image don’t change from one frame to another, GIFsicle doesn’t carry over the duplicate pixel information. The way to run it is:

> gifsicle -O2 src.gif > dest.gif

Smush.it

As we said at the beginning, the beauty of those four steps is that they don’t cause quality loss, so you don’t have to open and compare the results before and after. They are also all command-line tools that can be automated easily. So you have nothing to lose by running all your images through those tools before you FTP them to your web server, you can only win.

And you can always try the smush.it tool, just to get an idea of how much you can potentially save.

Share and extend: Bookmark with Yahoo! My Web | Bookmark with del.icio.us | digg it! | reddit!

26 Comments »

RSS feed for comments on this post. TrackBack URI

[...] Image Optimization Part 3: Four Steps to File Size Reduction [...]

Pingback by Image Optimization Part 2: Selecting the Right File Format » Yahoo! User Interface Blog — November 14, 2008 #
Great tip! On one of my web sites I ran all the jpegs through jpegtran and reduced the total file size by 9%. (4513 images, 507 MB reduced to 462 MB for a savings of 46 MB)

Comment by Michael Groh — November 14, 2008 #
Just thought I’d say thanks, this is a great post. The difficulty I see will be in automating these optimizations in an application’s build process.

Comment by Zach Leatherman — November 14, 2008 #
If you’re using ASP.NET, you can use this module to optimize your images on the fly.

It supports converting between png, gif, and jpg, and offers excellent compression.

It’s disk cached, so performance is a non-issue.

Comment by Nathanael Jones — November 14, 2008 #
Wow…this is very interesting. I didn’t even know that you can do stuff like this, Im going to keep this in mind the next time i save an image for the web.

Great post!

Ryan

Comment by Ryan Coughlin — November 15, 2008 #
Metadata that records authorship and copyright information may not add to the quality of display, but it does an essential job. By stripping this metadata you may unwittingly turn your image into an ‘orphan’ which can be freely stolen by other people. Do you really want to do this?

Comment by Peter Marquis-Kyle — November 15, 2008 #
Stoyan, thanks for mentioning the copyright info in your post. Perhaps the note under jpegtran about stripping copyright should be bolded.

To remove copyright info from the metadata is a big no-no. I fully understand and agree with other optimizations, but copyright/license info should remain at all costs.

Comment by Scott Southerland — November 16, 2008 #
I’ve gotta say, stripping metadata doesn’t gain you much, as we are talking bytes, not kilobytes so is probably not worth the effort.

I’ll question your 11.85% savings figure too – on the basis that pulling metadata out of spacer images doesn’t count.

Comment by Stephen De Gabrielle — November 16, 2008 #
I also dont have 11% savings. Only 2-3%.

How you get 11%? 0_o

Comment by bazzzman — November 17, 2008 #
Thanks very useful!!

Comment by Robert — November 17, 2008 #
Thanks for the comments everyone!

@Peter, @Scott, @Stephen – I realize the metadata is a sensitive optimization. The thing is that often there’s way more metadata than just author/copyright, I will try to work on an example that maintains copyright, but strips about everything else. Obviously jpegtran is not capable of doing this as it has a more all-or-nothing approach.

@bazzzman – if you’ve tried smush.it, it currently keeps all the metadata, so the savings are not really that impressive.

I tried running jpegtran on a much larger scale (10000+ images found on the web) than just top 10 sites and the results show that:

2% median savings when keeping all meta:
>jpegtran -copy all -optimize src.jpg dest.jpg
9% when striping all meta:
>jpegtran -copy none -optimize src.jpg dest.jpg
11% when striping all meta and using progressive encoding:
>jpegtran -copy none -progressive src.jpg dest.jpg

I’ll elaborate on these findings in a follow-up post.

Comment by Stoyan\ — November 17, 2008 #
@Stoyan, thanks for answer, I glad what you open for discussion ^____^

You are right, “-progressive” gives more savings, ыefore I used “-optimize”.
And what about quality? Is “-progressive” lossless?

I tried jpegtran on images from Photoshop CS2 (”Save for web…”, imgs as parts of sites design, ~500) and got:
“jpegtran -copy none -optimize” – 98%
“jpegtran -copy none -progressive” – 95%

Then I tried jpegtran on images from my photo cam (big, raw photos, ~1K) and got:
“jpegtran -copy none -progressive” – 91%

Conclusion: jpegtran is more useful on users pictures (photohosting, ect.). Hope this will be usefull for your researching :)

Comment by bazzzman — November 19, 2008 #
A few notes:

Progressive JPEGs don’t work in certain places. Flash Player is a big example. Only use progressive JPEGs if you know the only thing that’s going to be loading your images are normal browsers.

Jpegoptim gives better lossless optimization/compression than jpegtran, at least on average for me.

Comment by Kevin — November 20, 2008 #
OMG! smush.it is awsome.
Your post changed my life! uahuahauh very good stuff

Comment by fabiomcosta — November 21, 2008 #
[...] On unrelated stuff, Stoyan Stefanov from YUI blog has just posted a pretty neat article on pngcrush (among other things, like jpeg metadata stripper). This should really be made a common practice [...]

Pingback by Shattered Terminal » Blog Archive » Child sending naked picture of herself persecuted… — November 23, 2008 #
[...] si vous voulez quelques exemples de manipulation de ces scripts, Stoyan Stefanov a rédigé un article sur le [...]

Pingback by Optimiser ses images — November 25, 2008 #
Interesting, but I need to ask you something. I followed your directions and it worked fine except when my script got to gif files. I made a side by side comparison of gif files before conversion and after conversion and pngcrush. It turned out gif files were smaller by a 20 percent. Are you sure about your assumption that png files are always smaller than gif files? In my experience that is not true, except when you’re talking about png8 files.

Comment by picardo — December 4, 2008 #
[...] Image Optimization Part 3: Four Steps to File Size Reduction [...]

Pingback by Image Optimization, Part 4: Progressive JPEG…Hot or Not? » Yahoo! User Interface Blog — December 5, 2008 #
[...] Image Optimization Part 3: Four Steps to File Size Reduction [...]

Pingback by Image Optimization Part 1: The Importance of Images » Yahoo! User Interface Blog — December 5, 2008 #
[...] Image Optimization Part 3: Four Steps to File Size Reduction [...]

Pingback by Image Optimization, Part 5: AlphaImageLoader » Yahoo! User Interface Blog — December 8, 2008 #
Thank you for introducing imagemagic and pngcrush!

Comment by Alireza Tajary — December 14, 2008 #
But Web designers are meant to be blame when it comes to image design bcos they don’t get familiar with their Graphics applications. i use photoshop and could still get smaller images of any format. check this site to confirm. http://www.alsng.org. designed by me

Comment by Bolarinwa Olakunle Joshua — December 20, 2008 #
I went through a phase when I used to painstakingly ADD metadata to my images, such as keywords, descriptions etc. thinking that it would help with search engine ranking. Is this a waste of time?

Comment by Marathe — February 7, 2009 #
Stripping the metadata from jpgs or any image is a copyright infringement. These batch processes and methods of making file sizes smaller are interesting and could be useful, but for sites that are asking actual photographers to upload images and then strips the metadata out of the image as it “crunches” or “crushes” it is simply against the Digital Millennium Copyright Act

http://www.copyright.gov/legislation/dmca.pdf

http://en.wikipedia.org/wiki/Digital_Millennium_Copyright_Act

I appreciate the rest of your blog though.

Best,
Jackie Neale Chadwick

Comment by Jackie Neale Chadwick — March 20, 2009 #
I ran the Smush.it tool to this blog (http://yuiblog.com/blog/2008/11/14/imageopt-3/) and I found there is a scope of 14% image optimization.

Thanks for your nice post. I never read your blog. From now I am going to be a regular reader.

Comment by Monirul Islam — April 15, 2009 #
I was a huge fan of PNG8 for years. Then I noticed that there was a terrible color shift in the PNG’s versus GIF’s given the same color palette. If the images are stand alone like icons this may not be an issue, but when that image is used for a gradient that blends into a CSS background color, things can get problematic. The color shift is also problematic when the difference in contrast of the image color palette is small, such as beveled edges. The GIF would clearly show the bevel and match up with the adjacent colors whereas the PNG would not. I wish I had web site examples to share, but obviously these color shifts were not acceptable and the PNG’s never made it to the production site. This is not say I don’t use PNG’s or that you shouldn’t. Just be aware of color shifts.

Comment by TJ — June 5, 2009 #

Yahoo! User Interface Blog