Graphics Interchange Format

Jump to: navigation, search
Graphics Interchange Format
Rotating earth (small).gif
A rotating globe in GIF format. Posterization is noticeable in the blue gradient areas due to the restricted palette.
Filename extension .gif
Internet media type image/gif
Type code GIF
Uniform Type Identifier com.compuserve.gif
Magic number GIF87a/GIF89a
Developed by CompuServe
Type of format Raster graphics image format

The Graphics Interchange Format (GIF) is a bitmap image format that was introduced by CompuServe in 1987 and has since come into widespread usage on the World Wide Web due to its wide support and portability.

The format supports up to 8 bits per pixel, allowing a single image to reference a palette of up to 256 distinct colors chosen from the 24-bit RGB color space. It also supports animations and allows a separate palette of 256 colors for each frame. The color limitation makes the GIF format unsuitable for reproducing color photographs and other images with continuous color, but it is well-suited for simpler images such as graphics or logos with solid areas of color.

GIF images are compressed using the Lempel-Ziv-Welch (LZW) lossless data compression technique to reduce the file size without degrading the visual quality. This compression technique was patented in 1985. Controversy over the licensing agreement between the patent holder, Unisys, and CompuServe in 1994 spurred the development of the Portable Network Graphics (PNG) standard; since then all the relevant patents have expired.


An example of a non-animated GIF image.

CompuServe introduced the GIF format in 1987 to provide a color image format for their file downloading areas, replacing their earlier g (RLE) format, which was black and white only. GIF became popular because it used LZW data compression, which was more efficient than the run-length encoding that formats such as PCX and MacPaint used, and fairly large images could therefore be downloaded in a reasonably short time, even with very slow modems.

The original version of the GIF format was called 87a. In 1989, CompuServe devised an enhanced version, called 89a,[1] that added support for multiple images in a stream, interlacing and storage of application-specific metadata. The two versions can be distinguished by looking at the first six bytes of the file (the "magic number" or "signature"), which, when interpreted as ASCII, read "GIF87a" and "GIF89a", respectively.

GIF was one of the first two image formats commonly used on Web sites, the other being the black and white XBM.[citation needed] JPEG came later with the Mosaic browser.

The GIF89a feature of storing multiple images in one file, accompanied by control data, is used extensively on the Web to produce simple animations. The optional interlacing feature, which stores image scan lines out of order in such a fashion that even a partially downloaded image was somewhat recognizable, also helped GIF's popularity,[citation needed] as a user could abort the download if it was not what was required.


The creators of the format pronounced GIF with a soft "g", /ˈdʒɪf/, as in "George". However, many people pronounce GIF with a hard "G", as in a 'gift' /ˈɡɪf/,[citation needed] reflecting the way it is pronounced in its own acronym (Graphics Interchange Format). According to the creator of the GIF format, Steve Wilhite, the pronunciation deliberately echoes that of an American peanut butter brand, Jif, and the employees of CompuServe would often say "Choosy developers choose GIF", spoofing this brand's television commercials.[citation needed] This pronunciation was also identified by CompuServe in their documentation of a graphics display program called CompuShow.[2] Both pronunciations are given as correct by the Oxford English Dictionary[3] and the American Heritage Dictionary.[4]


Despite the GIF format's limitations, it can be used to display animation, as this animation of Newton's Cradle demonstrates.
An example of a short GIF animation made with a digital camera. The file is over 2MB in size.
  • GIFs are suitable for sharp-edged line art (such as logos) with a limited number of colors. This takes advantage of the format's lossless compression, which favors flat areas of uniform color with well defined edges (in contrast to JPEG, which favors smooth gradients and softer images).
  • GIFs can also be used to store low-color sprite data for games.
  • GIFs can be used for small animations and low-resolution film clips.
  • In view of the general limitation on the GIF image palette to 256 colors, it is not usually used as a format for digital photography. Digital photographers use image file formats capable of reproducing a greater range of colors, such as TIFF, RAW or the lossy JPEG, which is more suitable for compressing photographs.
  • The PNG format is a popular alternative to GIF images since it uses better compression techniques and does not have a limit of 256 colors, but PNGs do not support animations. The MNG and APNG formats, both derived from PNG, support animations, but are not widely used.[citation needed]


An example of a GIF image saved with a 'web-safe' palette and dithered using the Floyd-Steinberg method. Note that due to the reduced number of colors in the image, there are severe display issues.

GIF is palette based: although any palette selection can be one of millions of shades, the maximum number that can be used in a frame is 256. These are stored in a "palette", a table that associates each palette selection number with a specific RGB value. The limitation to 256 colors seemed reasonable at the time of GIF's creation because few people could afford the hardware to display more. Simple graphics, line drawings, cartoons, and grey-scale photographs typically need fewer than 256 colors. In addition, one of the colors in the palette can optionally be set as fully transparent. A transparent pixel takes on the color of the pixel in the same positions from the background, which may have been determined by a previous frame of animation.

There are ways to dither or diffuse photographs by using pixels of 2 or more different colors to approximate an in-between color, but this transformation inevitably loses some detail. The algorithms used to select the palette and to perform the dithering vary widely in output quality. Additionally, dithering significantly reduces the image's compressibility and thus works contrary to GIF's main purpose.

In the early days of graphical web browsers, graphics cards with 8-bit buffers (allowing only 256 colors) were common and it was fairly common to make GIF images using the websafe palette.[citation needed] This ensured predictable display but severely limited the choice of colors. Now that 32-bit graphics cards, which support 24-bit color, are the norm, palettes can be made up of the optimum colors for individual images.

True color

There are at least two rarely-used methods[5][6] that can generate a GIF that, if decoded according to the GIF89a standard, will produce an animation that ends with a 24-bit RGB truecolor image.

GIF89a was designed based on the principle of rendering images (known as frames when used for animation) to a logical, fixed-size screen. Each image could optionally have no delay after it is rendered, and could have its own 256-color palette. Also, each image need not fill the entire logical screen, and the animation can cease after the last frame; it need not begin again. The multi-frame, zero-delay, and unique-palette features, optionally combined with transparency, allow for each image to replace only a portion of the previous image's pixel data. When used without looping, a more-than-256-color final result can be achieved.

For example, a GIF can be encoded to render as a series of overlapping full-screen images, each image filling in color that wasn't in the previous one. Transparent pixels can be used to preserve colors from previous images.[7]

A similar method that doesn't use transparency is to encode the GIF to render as a series of less-than-full-screen images adjacent to each other, rather than overlapping.[8]

These methods are not widely supported by GIF-generating software, and Web browsers and other image viewers may not contain completely compliant GIF89a implementations, so their ability to display such GIFs accurately may be limited.

Example .gif file

Sample 3x5 pixels image.
Bytes Dh to 30Ch define a palette of 256 colors.

Microsoft Windows Vista's Paint program saves a small black and white image as the following .gif file. Due to overhead code such as an unnecessarily large color table this .gif file is not efficient for the image with only 15 pixels.

byte#  hexadecimal  text or
(hex)               value      Meaning
0:     47 49 46
       38 39 61     GIF89a     Header
                               Logical Screen Descriptor
6:     03 00        3           - width pixels
8:     05 00        5           - height pixels
A:     F7                       - GCT follows for 256 colors with resolution 3 x 8bits/primary
B:     00           0           - background color #0
C:     00                       - default aspect ratio
                   R    G    B Global Color Table
D:     00 00 00    0    0    0  - color #0 black
10:    80 00 00  128    0    0  -       #1
 :                                       :
85:    00 00 00    0    0    0  - color #40 black
 :                                       :
30A:   FF FF FF  255  255  255  - color #255 white
30D:   21 F9 04                Graphic Control Extension
310:   01                       - transparency is possible
311:   00 00                    - delay for animation: not used
313:   10          16           - color #16 is transparent
314:   00                       - end
315:   2C                      Image Descriptor
316:   00 00 00 00 (0,0)        - scan pixels from left top...
31A:   03 00 05 00 (3,5)        - right bottom.
31E:   00                       - end
31F:   08           8          LZW min. code size
320:   0B          11          11 bytes LZW encoded image data follow
321:   00 51 FC 1B 28 70 A0 C1 83 01 01
32C:   00                       - end
32D:   3B                      GIF file terminator

Image coding

The image pixel colors, scanned horizontally from top left, are converted by LZW encoding to codes that are then mapped into bytes for storing in the file. For the sample image above the reversible mapping between 9-bit codes and bytes is shown below.

9-bit   binary   Bytes
(hex)            (hex)
        00000000  00
       0101000|1  51
       111111|00  FC
       00011|011  1B
       0010|1000  28
       011|10000  70
       10|100000  A0
       1|1000001  C1
        10000011  83
        00000001  01
       0000000|1  01

A slight compression is evident: pixel colors defined initially by 15 bytes are exactly represented by 12 code bytes including control codes. The encoding process that produces the 9-bit codes is shown below. A local string accumulates pixel color numbers from the palette, with no output action as long as the local string can be found in a code table. There is special treatment of the first two pixels that arrive before the table grows from its initial size by additions of strings. After each output code, the local string is initialized to the latest pixel color (that could not be included in the output code).

                          Table           9-bit
                     string --> code      code    Action
                          #0 | 000h               Initialize root table of 9-bit codes
                    palette  |  :
                     colors  |  :
                        #255 | 0FFh
                         clr | 100h
                         end | 101h
                             |            100h     Clear
Pixel          Local         |
color Palette  string        |
BLACK  #40     28            |            028h     1st pixel always to output
WHITE  #255    FF            |                     String found in table
                  28 FF      | 102h                Add 1st string always to table
               FF            |                     Initialize local string
WHITE  #255    FF FF         |                     String not found in table
                             |            0FFh     - output code for previous string
                  FF FF      | 103h                - add latest string to table
               FF            |                     - initialize local string
WHITE  #255    FF FF         |                     String found in table
BLACK  #40     FF FF 28      |                     String not found in table
                             |            103h     - output code for previous string
                  FF FF 28   | 104h                - add latest string to table
               28            |                     - initialize local string
WHITE  #255    28 FF         |                     String found in table
WHITE  #255    28 FF FF      |                     String not found in table
                             |            102h     - output code for previous string
                  28 FF FF   | 105h                - add latest string to table
               FF            |                     - initialize local string
WHITE  #255    FF FF         |                     String found in table
WHITE  #255    FF FF FF      |                     String not found in table
                             |            103h     - output code for previous string
                  FF FF FF   | 106h                - add latest string to table
               FF            |                     - initialize local string
WHITE  #255    FF FF         |                     String found in table
WHITE  #255    FF FF FF      |                     String found in table
WHITE  #255    FF FF FF FF   |                     String not found in table
                             |            106h     - output code for previous string
                  FF FF FF FF| 107h                - add latest string to table
               FF            |                     - initialize local string
WHITE  #255    FF FF         |                     String found in table
WHITE  #255    FF FF FF      |                     String found in table
WHITE  #255    FF FF FF FF   |                     String found in table
                                                   No more pixels
                                          107h     - output code for last string
                                          101h     End

For clarity the table is shown above as being built of strings of increasing length. That scheme can function but the table consumes an unpredictable amount of memory. Memory can be saved in practice by noting that each new string to be stored consists of a previously stored string augmented by one character. It is economical to store at each address only two words: an existing address and one character.

The LZW algorithm requires a search of the table for each pixel. A linear search through up to 4096 addresses would make the coding slow. In practice the codes can be stored in order of numerical value; this allows each search to be done by a SAR (Successive Approximation Register, as used in some ADCs) and only 12 magnitude tests. For this efficiency an extra table is needed to convert between codes and actual memory addresses; the extra table upkeeping is needed only when a new code is stored which happens at much less than pixel rate.

Image decoding

Decoding begins by mapping the stored bytes back to 9-bit codes. These are decoded to recover the pixel colors as shown below. A table identical to the one used in the encoder is built by adding strings by this rule:

Is incoming code found in table?
 YES: add string for local code followed by first byte of string for incoming code
 NO:  add string for local code followed by copy of its own first byte
9-bit ----> Local      Table                 Pixel
code        code   code --> string   Palette color  Action
100h               000h  | #0                       Initialize root table of 9-bit codes
                    :    | palette
                    :    | colors
                   0FFh  | #255
                   100h  | clr
                   101h  | end
028h                     |             #40    BLACK Decode 1st pixel
0FFh        028h         |                           Incoming code found in table
                         |             #255   WHITE  - output string from table
                   102h  | 28 FF                     - add to table
103h        0FFh         |                           Incoming code not found in table
                   103h  | FF FF                     - add to table
                         |                           - output string from table
                         |             #255   WHITE
                         |             #255   WHITE
102h        103h         |                           Incoming code found in table
                         |                           - output string from table
                         |             #40    BLACK
                         |             #255   WHITE
                   104h  | FF FF 28                  - add to table
103h        102h         |                           Incoming code found in table
                         |                           - output string from table
                         |             #255   WHITE
                         |             #255   WHITE
                   105h  | 28 FF FF                  - add to table
106h        103h         |                           Incoming code not found in table
                   106h  | FF FF FF                  - add to table
                         |                           - output string from table
                         |             #255   WHITE
                         |             #255   WHITE
                         |             #255   WHITE
107h        106h         |                           Incoming code not found in table
                   107h  | FF FF FF FF               - add to table
                         |                           - output string from table
                         |             #255   WHITE
                         |             #255   WHITE
                         |             #255   WHITE
                         |             #255   WHITE
101h                     |                           End

LZW code lengths

Shorter code lengths can be used for smaller palettes than the 256 (maximum) colors in the example. The code table initially contains codes that are one bit longer than the palette size in order to give additional space for two special codes clr and end and for strings that are added during the process. When the table is full the code length increases to give space for more strings, up to a maximum code 4095 = FFF(hex). As the decoder builds its table it tracks these increases in code length and it is able to unpack incoming bytes accordingly.

Non-compressed .gif

The standard allows a coder to insert a 'clr' code at any time in the image data, which implicitly allows .gif files to be created without LZW compression. The coding table then need never grow beyond the 'end' code value. At the cost of larger file size this gives advantages of simpler coding with a 1:1 correspondence of pixels and palette codes while keeping compatibility with ordinary .gif displays. It has been used to avoid infringing patents covering LZW. For the example 3x5 image above the following 9-bit codes represent 'clr' followed by image pixels in scan order and 'end'.

9-bit codes: 100 028 0FF 0FF 0FF 028 0FF 0FF 0FF 0FF 0FF 0FF 0FF 0FF 0FF 0FF 101

After the above codes are mapped to bytes the non-compressed file differs from the compressed file thus:

320: 14            20            20 bytes non-compressed image data follow
321: 00 51 FC FB F7 0F C5 BF 7F FF FE FD FB F7 EF DF BF 7F 01 01
335: 00                          - end

Animated .gif

GIF is designed to allow users to define new blocks. In the 1990s, Netscape designed the Netscape Application Block,[9] which indicates that a GIF file is an animation instead of a static image. Support for these animations first appeared in Netscape Navigator version 2.0, then spread to other browsers.[10]

An animated .gif file comprises a number of images or frames to be displayed successively, each described by its own GCE (Graphic Control Extension), preceded by a header whose content by default applies to all the frames. After the header the data is stream-oriented instead of being at fixed indices, so the location of the start of a GCE depends on the length of preceding GCE(s). Within a GCE the LZE-coded image data is arranged in blocks each of up to 255 bytes; the size of block is declared by a byte that precedes it. Below is the structure of the animation Rotating earth (large).gif:

byte#  hexadecimal  text or
(hex)               value      Meaning
0:     47 49 46
       38 39 61     GIF89a     Header
                               Logical Screen Descriptor
6:     90 01        400         - width pixels
8:     90 01        400         - height pixels
A:     F7                       - GCT follows for 256 colors with resolution 3 x 8bits/primary
B:     00           0           - background color #0
C:     00                       - default aspect ratio
D:                             Global Color Table
30D:   21 FF 0B                Application Extension
310:   4E 45 54
       53 43 41
       50 45 32
       2E 30        NETSCAPE2.0
31B:   03 01                    - data follows
31D:   FF FF                    - loop animation
31F:   00                       - end
320:   21 F9 04                Graphic Control Extension frame #1
323:   08                       - no transparency
324:   09 00                    - 0.09 sec duration
325:   00                       - no transparent color
327:   00                       - end
328:   2C                      Image Descriptor
329:   00 00 00 00  (0,0)       - scan pixels from left top...
32D:   90 01 90 01  (400,400)   - right bottom
331:   00                       - end
332:   08           8          LZW min code size
333:   FF           255        255 bytes LZW encoded image data follow
334:                data
433:   FF           255        255 bytes LZW encoded image data follow
92BA:  00                      end
92BB:  21 F9 04                Graphic Control Extension frame #2
 :                                                              :
153B7B:21 F9 04                Graphic Control Extension frame #44
15CF35:3B           1 429 301  File terminates

The GCEs allow the duration for which each frame is displayed to be specified in hundredths of second. Some economy of data is possible where a frame need only rewrite a portion of the pixels of the display, because the Image Descriptor can define a smaller rectangle to be rescanned instead of the whole image. Displays that do not support animated .gifs show only the first frame.

Unisys and LZW patent enforcement

In 1977 and 1978, Jacob Ziv and Abraham Lempel published a pair of papers on a new class of lossless data-compression algorithms, now collectively referred to as "LZ77" and "LZ78". In 1983, Terry Welch developed a fast variant of LZ78 which was named Lempel–Ziv–Welch (LZW).[11][12]

Welch filed a patent application for the LZW method in June 1983. The resulting patent, US patent 4558302, granted in December 1985, was assigned to Sperry Corporation who subsequently merged with Burroughs Corporation in 1986 and formed Unisys.[11] Further patents were obtained in the United Kingdom, France, Germany, Italy, Japan and Canada.

In June 1984, an article by Welch was published in the IEEE magazine which publicly described the LZW technique for the first time.[13] LZW became a popular data compression technique and, when the patent was granted, Unisys entered into licensing agreements with over a hundred companies.[11][14]

The popularity of LZW led CompuServe to choose it as the compression technique for their GIF format, developed in 1987. At the time, CompuServe was not aware of the patent.[11] Unisys became aware that the GIF format used the LZW compression technique and entered into licensing negotiations with CompuServe in January 1993. The subsequent agreement was announced on December 24, 1994.[12] Unisys stated that they expected all major commercial on-line information services companies employing the LZW patent to license the technology from Unisys at a reasonable rate, but that they would not require licensing, or fees to be paid, for non-commercial, non-profit GIF-based applications, including those for use on the on-line services.[14]

Following this announcement, there was widespread condemnation of CompuServe and Unisys, and many software developers threatened to stop using the GIF format. The PNG format (see below) was developed in 1995 as an intended replacement.[11][12][13] However, obtaining support from the makers of Web browsers and other software for the PNG format proved difficult and it was not possible to replace the GIF format, although PNG has gradually increased in popularity.[11]

In August 1999, Unisys changed the details of their licensing practice, announcing the option for owners of Billboard and Intra net Web sites to obtain licenses on payment of a one-time license fee of $5000 or $7500.[15] Such licenses were not required for website owners or other GIF users who had used licensed software to generate GIFs. Nevertheless, Unisys was the subject of thousands of online attacks and abusive emails from users believing that they were going to be charged $5000 or sued for using GIFs on their websites.[16] Despite giving free licenses to hundreds of non-profit organizations, schools and governments, Unisys was completely unable to generate any good publicity and continued to be vilified by individuals and organizations such as the League for Programming Freedom who started the "Burn All GIFs" campaign.[17]

The US LZW patent expired on June 20, 2003.[18] The counterpart patents in the United Kingdom, France, Germany and Italy expired on June 18, 2004, the Japanese counterpart patents expired on June 20, 2004 and the counterpart Canadian patent expired on July 7, 2004.[18] Consequently, while Unisys has further patents and patent applications relating to improvements to the LZW technique,[18] the GIF format may now be used freely.

PNG and other alternatives

Portable Network Graphics (PNG) was designed as a replacement for the GIF format in order to avoid infringement of Unisys' patent on the LZW compression technique.[11] PNG offers better compression and more features than GIF[19]. The format is more suitable than GIF in instances where true-color imaging and alpha transparency are required. MNG was originally developed as a PNG-based solution for animations, but has not been widely adopted. The GIF format is still preferred for animation over PNG, although true Animated Portable Network Graphics are under development by Mozilla and are supported in Firefox 3.[20][21]

Although it took time for the PNG format to be supported, new web browsers support the PNG format, and GIF images can now be replaced by PNG images. However, Internet Explorer versions 6 and earlier do not support PNG's alpha channel transparency feature without using Microsoft-specific HTML extensions.[22] Using standard HTML <img> tags for PNG images in Internet Explorer can produce a look different from that intended. Internet Explorer 7 supports alpha channel transparency without needing extensions. No versions of Internet Explorer, however, support the gamma feature of PNG images, and the display of these images may be of the wrong tint.[23]

PNG image files are generally smaller than GIF files of the same image quality, due to the more efficient compression techniques used in PNG encoding[24]. PNG files can indeed be much larger than GIF files in situations where a GIF and a PNG file were created from a high-quality master image, as PNG is capable of storing more color depth and transparency information than GIF. However, for identical 8-bit (or lower) image data, PNG-format image files are almost always smaller than the equivalent GIF. Misinformation about PNG efficiency can generally be traced back to poor PNG support in older versions of some image manipulation programs, (for example Adobe Photoshop did not optimize PNGs for reduced color palettes by default).[citation needed] A working solution is pngcrush. Generally it can be noted that also a proper support for (animated) GIF is difficult: complicated canvas, redundant color entries, dictionary resets.[clarification needed] Also note the complicated interaction between color quantization, compression (especially in animations) and dithering noted in the former reference which is obsolete with PNG.[clarification needed]

In 2004, an extension to the PNG format called APNG was suggested. It was to provide the ability to animate PNG files, while retaining backwards compatibility in decoders that cannot understand the animation chunk. Older decoders will simply render the first frame of the animation.

MNG, a variant of PNG that supports animation, reached version 1.0 in 2001, but few applications support it. Animated GIF remains widely used as many applications are capable of creating the files, and it remains the only animated image format capable of being rendered in nearly all modern Web browsers without the use of a plug-in.[25] Nevertheless, embedded Flash objects, MPEGs and other video formats are used in place of animated GIFs in many websites. Other approaches, such as individual frames served by AJAX, or SVG images may be animated via JavaScript or SMIL.

See also

  • Comparison of graphics file formats
  • Comparison of layout engines (graphics)
  • Software patent
  • GNU plotutils (supports pseudo-gif format which uses g rather than LZW)


  1. "Cover Sheet for the GIF89a Specification". W3C. July 31, 1990. Retrieved March 6, 2009. 
  2. Olsen, Steve. "The GIF Pronounciation Page". Retrieved March 6, 2009. "CompuServe used to distribute a graphics display program called CompuShow. In the documentation for version 8.33 in the FAQ section, it states: The GIF (Graphics Interchange Format), pronounced "JIF", was designed by CompuServe and the official specification released in June of 1987." 
  3. "Oxford English Dictionary". Oxford University Press. Retrieved 2007-04-15. 
  4. "American Heritage Dictionary". Houghton-Mifflin. Retrieved 2007-04-15. 
  5. GIF 24 Bit (truecolor) extensions
  6. Itsagif Layers
  7. This method is demonstrated by Pedagoguery Software's Itsagif software for Windows and older Macintosh OSes.
  8. This method is explained in detail by Andreas Kleinert in his GIF 24 Bit (truecolor) extensions document, and is demonstrated on Philip Howard's True-Color GIF Example Web page, which uses his angif C library. The demo uses blocks of size 16 by 16 pixels, allowing for up to 256 unique colors, 1 per pixel, the maximum each block's palette can support.
  9. All About GIF89a, Royal Frazier, 1997
  10. Scott Walter (1996). Web Scripting Secret Weapons. Que Publishing. ISBN 0789709473. 
  11. 11.0 11.1 11.2 11.3 11.4 11.5 11.6 History of the Portable Network Graphics (PNG) Format by Greg Roelofs
  12. 12.0 12.1 12.2 Sad day... GIF patent dead at 20
  13. 13.0 13.1 The GIF Controversy: A Software Developer's Perspective
  14. 14.0 14.1 Unisys Clarifies Policy Regarding Patent Use in On-Line Service Offerings - archived by League for Programming Freedom
  15. LZW Software and Patent Information - clarification of 2 September 1999
  16. Unisys Not Suing (most) Webmasters for Using GIFs - Slashdot investigation into the controversy
  17. Burn All GIFs - A project of the League for Programming Freedom
  18. 18.0 18.1 18.2 License Information on GIF and Other LZW-based Technologies
  19. "PNG versus GIF Compression". Retrieved June 8, 2009. 
  20. APNG Specification - MozillaWiki
  21. Mozilla Labs » Blog Archive » Better animations in Firefox 3
  22. AlphaImageLoader Filter
  23. "What's New in Internet Explorer 7". MSDN. Retrieved March 6, 2009. 
  24. "PNG Image File Format". Retrieved June 8, 2009. 
  25. Staples, Tanya; Weinman, Lynda (2005). Adobe Photoshop CS2 for the Web: Hands-on Training. Peachpit Press. 

External links