The latest Fiddler beta v2.4.2.5 (targeting .NET2 or .NET4) includes several improvements to the ImageView Response Inspector. While its appearance remains mostly unchanged, the new version provides much more insight into the metadata often included with image files. Read on for more details.

GIFs

GIF images are limited to 256 colors, are losslessly-compressed, and support animation and transparency. When a GIF file is selected in Fiddler’s Web Sessions list, the ImageView Inspector’s sidebar shows the size and dimensions of the image, as well some GIF-specific fields:

The Frames field shows the number of frames (images) contained within this GIF. These frames are cycled through to animate the image.

The Delay field shows the range of delays for each frame; most animated GIFs are configured with a fixed delay between each frame (e.g. showing 10 frames per second) but some are carefully coded with a different delay between each frame. Notably, some browser versions do not respect delays below 50ms.

The Loops field shows the number of times that the image should animate. A value of 0 means that the image should animate through all of the frames without stopping. A value of 1 means that the image should stop animating after each frame is shown once. Notably, all Internet Explorer versions, up-to-and-including IE10, incorrectly interpret a value of 1 as a request to go through the loop twice.

Optimizing GIFs

In most cases, non-animated GIF images can be reduced in size (maintaining 100% quality) by converting them to PNG images. For instance, Microsoft’s SmartScreen page includes two GIF files which can be made roughly 20% smaller when converted to PNG using the freeware PNGOut tool:

Animated GIFs cannot be converted to PNGs, but may be optimized using the open-source Gifsicle utility, which de-duplicates redundant information between frames.

PNG

PNG images support palettes or RGBA full-color, transparency, and are losslessly-compressed. The image format is easily parsed and may contain a wide variety of embedded metadata including comments, Last-Modified dates, Gamma- and color-correction information, and much more.

The ImageView sidebar shows the image’s size and dimensions and the most common types of metadata.

The Color field shows what type of color the image uses (Grayscale, Palette, RGBA) as well as how many bits are used.

The Gamma field, if present, indicates the “relationship between the image samples and the desired display output intensity.” Unfortunately, gamma-correction is often implemented incorrectly, and as a consequence you may want to strip the Gamma chunk from your PNG image if you want consistent display across browsers.

The iCCP field, if present, contains information that can be used for color-correction in the image.

The Last-Modified field, if present, shows the time that the image file was last-modified. This field is typically set by the image capture device or editor, and thus will likely differ from the HTTP Last-Modified header value.

The Interlace field, if present, indicates what type of interlacing is used within the image.

PNG supports three types of comment chunks; these will be shown in a Comments section within the sidebar. The total size of all comments is shown parenthetically after the heading.

Within the comment list, entries labeled Comment contain a simple ASCII comment. Those labeled zComment were stored in the file using ZLib compression; Fiddler automatically decompresses the text for display. Those labeled iComment were stored in UTF-8, and may be have been compressed with Zlib.

If you’d like to spelunk through all of the chunks in a PNG image, export the image from Fiddler and use the open-source PNGTweak utility to open the file.

Optimizing PNGs

There are several strategies to optimize PNG files; these range from conservative to aggressive. As a conservative and very simple optimization, remove unnecessary metadata comments-- these are silently added by image-editing tools.

For instance, my bank’s website sends a 975 byte PNG file that contains 851 bytes of textual comments (added by Adobe ImageReady). These comments have no meaning to a browser, and when removed, the resulting image is under 13% of its original size. The full story is actually worse than that: the bank website sends several such bloated PNGs which should be combined into a sprite and then optimized.

Beyond the simplest optimizations, you can often shrink PNG files by reducing their color count. Instead of using 24bit color, for instance, you may be able to convert your image to use an 8bit palette. I undertook this strategy when I optimized the images on the Fiddler Extensions page. This 742x304 pixel image, for instance, was originally saved as a PNG using 24bit color. I used the open-source pngquant tool to convert this image to an 8-bit palette. The resultant image is only 54% as large as the original, and is visually indistinguishable. A few minutes of applying such optimizations shrank the overall weight of images on the page from 1090kb to 462kb, a huge bandwidth savings for me, and significant performance improvement for visitors.

A large number of image-optimization tools are available; have a look at this article for a good list, and check out this blog series and this post for discussion of image optimization in general.

JPEG

JPEG images support RGB truecolor, and are lossily-compressed in a manner best suited for photographs. Like PNG files, JPEGs also can contain huge blocks of hidden metadata and often benefit from optimization.

Progressive JPEG

JPEG images support an interesting feature called progressive rendering whereby the full-sized image first appears on the page at low-quality early in the image’s download. Then the quality of the image subsequently improves as the remainder of the image is read from the network.

This behavior is generally deemed a perceived-performance benefit (because users aren’t left with large blank areas) but I was fascinated to learn that enabling this behavior also makes most JPEGs over 10kb smaller in size (due to how JPEG compression works). If you’re interested in learning the full details, check out this great post: Progressive jpegs: a new best practice.

The ImageView inspector detects whether an image is Progressive or not (Baseline) and notes this information in the sidebar.

JPEG Metadata (EXIF)

JPEG files often contain a large quantity of metadata (also known as “APP#” segments) which takes up space but does not impact rendering in browsers. Such metadata may include thumbnail images, comments, modification dates, copyright info, detailed camera information, and detailed information about the photo itself (e.g. aspect ratio, did the flash fire, where was the camera located, etc.). Sometimes, JPEG files even include large blocks of empty padding (to simplify later updates to the file on CPU-poor devices).

Comments in JPEG files are not compressed and thus should be removed if possible. In some cases, a photographer may deliberately embed a great deal of information. In the images on this page for instance, some of the comments are over 1kb in size.

The ImageView will flag images that contain a thumbnail or comments and note that in the sidebar. Images containing geolocation information will also be noted (more on that in my next post).

If you want an extremely thorough analysis of the metadata within a JPEG, export it from Fiddler and use the open-source JPEGSnoop to examine the file.

Optimizing JPEGs

The most popular JPEG optimization tool is jpegtran; this tool can easily strip JPEGs of metadata and convert baseline JPEGs to progressive.

Jpegtran’s optimizer can also generate image-specific Huffman-coding tables for improved compression. The ImageView sidebar notes the presence of optimized compression tables in an HuffmanTables: # entry; a JPEG may contain up to 4 such tables.

WebP – Some assembly required

Google’s WebP image format was introduced in 2010 and designed to provide enhanced compression when compared to existing image formats. WebP supports both lossy and lossless compression mechanisms, enabling it to serve as an alternative to both PNG and JPEG. However, this format is currently only supported in Chrome and Opera, which means it is not commonly used on the Web. This may change in the future, as the format is likely to be supported in Firefox shortly, and it appears to offer significant size savings over both PNG and JPEG.

Windows and .NET do not natively support the WebP format, and prior to the latest beta version, Fiddler could not render WebP images. In the beta, however, the ImageView inspector can seamlessly render WebP images:

This feature works by silently converting the WebP to a temporary PNG file and rendering the PNG file using the existing .NET support.

The conversion is provided by the dwebp.exe command-line tool. You can download the utility from Google’s WebP downloads page. Simply copy the executable from inside libwebp-0.2.1-windows-x86.zip to a Tools subfolder of the Fiddler install folder (e.g. C:\Program Files (x86)\Fiddler2\Tools\).

Also included in the package is cwebp.exe, a tool that will convert JPEG and PNG files into WebP format. The converter offers a number of command-line options to explore. Some of its results can be surprising; for instance it converted my 84kb test PNG file to a 62kb WebP image using lossy compression, and a 44kb WebP image using lossless compression.

JPEG-XR

Fiddler does not currently support Microsoft’s JPEG-XR format that was designed to compete with classic JPEGs and WebP. At the moment, the JPEG-XR variant appears to have little adoption. If it becomes more popular, I will look into enhancing Fiddler to better support it.

Feature Requests?

Fiddler’s support for image formats just got a lot richer. Are there other scenarios where Fiddler-enhancements could make your job easier or more interesting?