Home PNG, JPEG, and Fractals
Information : Semi-Technical : PNG, JPEG, and Fractals
Search

A
rguments over the relative merits of file formats are not new, and often seem to have all the traits of religious holy wars (except the casualties are only egos). For web use, the only choice at first was Graphical Interchange Format (GIF). Soon Joint Photographic Experts Group (JPEG) was added; and now finally there is a third choice, Portable Network Graphic (PNG). Which one is best depends very much on what you want to use it for.
    Deciding between GIF and JPEG (before PNG hit the scene) was easy: any 24-bit color depth (16.7 million colors) photographic-style image became a JPEG, while images with less color, transparent areas, or animation were GIFs; however, PNG complicates things because it offers some features common to both formats, as well as a few unique features. To give you a little background, I'll first spend a bit of time explaining a little about each format.
 
GIF

This is a relatively simple format, developed in 1987 by CompuServe as a means for computer users to share pictures online, even if they weren't the same type of computer. It can handle pictures with up to 256 colors.1 Through extensions to the format introduced in 1989, GIF supports animations as well. GIF also allows one of the colors in the image to be transparent.
    GIF files are compressed using a lossless scheme called LZW. Lossless just means that no information is lost during the compression process; when the image is decompressed for display, it will look exactly the same as the original, uncompressed image. LZW compression can often achieve 2:1 compression ratios for an image--meaning the uncompressed image is twice as large as the compressed file.
 
JPEG

Developed in the late 1980s and early 1990s as a new standard for photographic images, JPEG is very different from GIF. The biggest difference is that JPEG uses lossy compression schemes. Lossy means that when an image is compressed, stored in a JPEG, and later decompressed, it will be slightly different from the original, uncompressed image. The rationale for such an odd concept is that if you can't tell the difference, it doesn't matter (for casual viewing) if the images aren't the same. If a little bit of data can be discarded to improve the compression dramatically, it may be worth it. It's common for JPEG's lossy algorithms to achieve 10:1 compression (the uncompressed file is ten times the size of the compressed file) without substantial loss in image quality.
    The full JPEG standard has a lot of features that most JPEG-capable programs do not use. In practical situations, JPEG can handle 24-bit full-color images and 8-bit grey-scale images. It does not handle 256-color images directly.
 
PNG

Pronounced "ping", this is a relatively new (1995) format that was designed to replace GIF. It handles images up to 256 colors, like GIF, but it also handles 24-bit images like JPEG. It supports transparency, like GIF, but also does it one better: rather than simple on/off transparency, it allows a full range of "partially transparent" values. (Techies will note this means "alpha channel".) PNG doesn't support animations, but the MNG format (a variety of PNG, not widely supported) does.
    Like GIF, PNG uses lossless compression. But PNG's compression is based on a scheme called LZ77, which isn't patented (LZW is).2 PNG's compression is usually about 25% better than GIF's.
    PNG support in web browsers is not always consistent. All modern browsers support basic PNG display, but Microsoft's Internet Explorer does not support PNG's partial transparency feature without some very ugly work-arounds.
 
JPEG on Photographs

If JPEG compression is so great, why not use it for everything? Why waste time with 2:1 or 3:1 compression in GIF and PNG, when 10:1 is so much better? The answer is that that 10:1 compression comes at a price: it's lossy. What you get when you uncompress the image isn't the same as what you put into it.
    JPEG was designed for photographic images. The compression scheme it uses (DCT) is very specific to real-life images. Think of it as breaking down the image into small blocks, and sorting out how quickly colors change within that block, from one side to the other. In photographic scenes, those changes have certain, somewhat predictable characteristics. Some of those characteristics are visually important; some are visually irrelevant. By changing the irrelevant parts to values that help compress the data better, overall compression can be improved a lot. And since only the visually irrelevant bits have been changed, you won't notice the changes when you uncompress the image. What's even nicer is you can usually tell your JPEG software how much data it should consider relevant; the more data that's considered unimportant, the more it can be adjusted to improve compression and reduce the size of the file.
    Of course, this assumes from the start that you're working with a photographic image. Those visually irrelevant bits may not be so irrelevant for a different type of image, such as a fractal, a hand-drawn image, or even a simple cartoon-like drawing. How do you know if an image is good JPEG material? Fortunately this is pretty easy: look for sharp transitions, any place where there is an extremely abrupt change from one color or shade to another. If your image has a lot of these, JPEG is going to have some problems.
    It's time for some examples. Here are three versions of the same photographic image:

32K8K5K

(This is from a larger photo; you can see the full imageThis link leads to another site..) It's common in software that supports JPEG to allow a "quality" or "compression" setting, in the range 1-100, which lets the user set how much information is considered relevant. Setting the value higher results in more compression (and more loss). The image on the left was produced by setting the value at its minimum--least compression, least loss. It is 32K. The center image was produced with a compression setting of 10; it is 8K. And the image on the right was done with a compression setting of 30; it's less than 5K. But you can see it's a little blurrier than the others. An uncompressed version of this image would be 90K.
    Let's have a look at just how different those pictures are from the original, uncompressed version. This next set of images represent the difference between the images above and the uncompressed, non-JPEG version. Because the differences are so slight, I've exaggerated them ten times to make them visible. Black indicates no difference, white indicates a difference of one tenth of the full brightness range.


First, note that even with the differences exaggerated by a factor of ten, the image saved at the highest quality shows virtually no visible difference. Next, note that in the other images, the largest differences occur near transitions--edges in the original image. (We'll come back to that point later.)
    If you're still not convinced that JPEG is good for photographs, consider this: if you did not know which of the three sample JPEGs was compressed the most, how long would it take you to decide?
 
JPEG on Fractals

Now that I've just gotten through showing you how great JPEG works on photographs, I'll show you why it's often stated that JPEG should never be used for fractals. (Then I'll show you the right way to do it.)

23K18K8K

(This is a clip from Dragon's Tail.) The first image in this case is a 256-color GIF; it represents the lossless output from FractInt, where the image was generated. It's 23K. The second image uses a compression setting of 10 (and is 18K), and the third uses a compression setting of 30 (it's 8K).
    You've no doubt already noticed that even at quality 10, the JPEG version looks pretty hideous; it's muddy and just generally unattractive. The compression-30 version is totally unacceptable. If this were the best JPEG had to offer, then I would agree with the common wisdom that JPEG and fractals don't mix.
    These JPEGs were produced by simply loading the 256-color GIF into a graphics program, then saving the results out as JPEGs. This is absolutely not the way to produce decent fractal JPEGs, but just in case you're not convinced yet, here are the difference images:


As you can see, there are substantially more differences between the JPEG versions and the original image than in the case of the photograph. The problem arises from the presumed subject matter of JPEG: photographic images. In a photograph, you don't have very many sharp edges. What you perceive as a sharp edge is usually spread out over several pixels. JPEG is highly sensitive to sharp edges; it doesn't deal with them at all well. You can see in the example fractal image that the worst errors appear at the razor-sharp transitions.
    Fortunately, it's possible to do a lot better with JPEG and fractals. The most important step you can take is to anti-alias the image--create the fractal at a higher resolution than you intend to use, then use a graphics program to reduce the size. (Not sure this is mathematically appropriate for fractals? Perhaps this page will change your mind.) Anti-aliasing will smooth out some of the sharp edges, making them friendlier to JPEG. Anti-aliasing also results in a 24-bit image (even if you started out with a 256-color fractal). Although this means you're now starting from a file three times the size of a 256-color image, you can easily make up that difference (and then some) by properly compressing the file as a JPEG. Here is the same fractal clip, but starting from an anti-aliased version of the image:

58K20K7K

As with the other examples, these were created with compression settings of 1, 10, and 30, respectively. Compare the 10 setting here with the lossless GIF above. The JPEG is 3K smaller, and it's anti-aliased. The compression setting of 30 still looks terrible, though; I've included it to illustrate an important lesson for fractal JPEG saving: don't set the compression too high.
    To be complete, here are the difference images for the anti-aliased fractal JPEGs. Remember these are exaggerated tenfold.


You can see here that the compression-10 image has a lot less error than saving the 256-color version in a JPEG at the same compression setting was able to achieve.
 
4:4:4 and 4:2:2

JPEG actually offers two kinds of loss. One is the quality/compression slider I've already referred to. The other is color subsampling. The idea here is that the human eye is more sensitive to changes in brightness than it is to changes in color. So one of the options in the JPEG format--very commonly used--is to store the color data at only half the resolution of the brightness data. (JPEG doesn't use RGB, it uses a color system that has a single brightness channel, Y, and two color channels, Cb and Cr.) For photographs, this is good; real photos don't have sharp color transitions any more than they have sharp brightness transitions, so this shouldn't cause a problem. But for fractals, color transitions very often occur with the same sharpness as brightness transitions, so disabling this JPEG feature will help enormously.
    The subsampling option is referred to as "4:2:2" sampling. This means for every four pixels of brightness data, there are 2 Cb and 2 Cr pixels of color data. You don't want that. You want "4:4:4" sampling, where there are equal (full) amounts of data in each channel. These images show the difference:

20K15K12K

For grins I've also included the virtually-useless 4:1:1 sampling (it's the murky image on the right). These files are 20K, 15K, and 12K, respectively. If your software doesn't seem to give you the option of setting this, it's probably using 4:2:2. This won't kill you, but it won't help; try looking for new software, or asking your software's author to change it.
 
So What About PNG?

And now, I can finally get to the reason I wrote this page in the first place: how does PNG stack up to JPEG? Obviously for photos it's not going to be a fair test; compare this compression-10 JPEG and the lossless PNG version:

8K54K

Not sure which is which? The one on the left is the 8K JPEG; the one on the right is the 54K PNG. Oops. I told you it wasn't a fair test.
    The reason you're here, though, is to answer the question, "should JPEG be used for fractals if PNG is available?" So here is a PNG version of the 256-color fractal, a compression-10 JPEG of the anti-aliased fractal, and the PNG version of the anti-aliased fractal.

18K20K69K

The anti-aliased versions, here visible next to the 256-color version, clearly look better; the finer detail is more discernable. You can probably see slight differences between the JPEG (center) and the PNG (right)--but the JPEG is only 20K, and the PNG is 69K! The JPEG is slightly bigger than the 256-color image, but it's probably worth it for the anti-aliasing. (In many cases the JPEG is actually smaller than the GIF.) But it's hard to argue that the small differences between the JPEG and the PNG are worth waiting three times as long for the image to download.
 
Summing Up

There are situations where it's not appropriate to use JPEG. Images with just a few colors, especially large areas of solid color, are better left as GIF or PNG files. Images that require transparency can't be stored in JPEG format. Animations have to be GIF. But any 24-bit image should be considered for JPEG. If the image has sharp transitions, see if anti-aliasing techniques can be applied. (This helps even 3D rendered images, although most 3D software includes anti-aliasing as a built-in feature.)
    It's also important to note that not all JPEG software is the same. A "compression 10" in one program doesn't get you the same thing as "compression 10" in another one--one might produce a bigger file, or the same file but with more loss. You will have to experiment to see where the "good" range with your software is. For these examples, I used Micrografx Picture Publisher 7 (which is no longer available). Adobe PhotoshopThis link leads to another site. (out of reach of most fractal enthusiasts) also has a good JPEG compressor. If the software you are using is producing lousy JPEGs from your fractals, it may not be because it's JPEG--it may be because the software is lousy! Check out some other software and see how it compares.
    In the interests of fairness, I should point out that not all PNG software is the same, either. PNG is still a new format, and it provides so many compression options that most PNG software at the moment probably only provides the bare minimum required to make PNG files. I used Picture Publisher for the JPEG files, but the PNG version of the photo was a whopping 79K, 45% bigger than the 54K PNG used above. The 54K PNG was produced by a program called pngcrushThis link leads to another site., which shows just how effective PNG can be. Note that the PNG files are still substantially larger than the JPEG files.
 
Footnotes

1Strictly speaking, GIF images can store an image with more colors through some creative use of the extensions to the format. However, not all software will properly interpret images created this way, and in some cases will process the image very slowly.

2The LZW patent was held by Unisys, which neglected to enforce it until GIF was in widespread use on the web, at which point Unisys opted to try to get royalties on the patent from software makers who used it to support the GIF standard. The last of those patents expired July 7, 2004.

  Return to Semi-Technical
Return to Information
Return to Entrance

Copyright © 1996-2004 Damien M. Jones