Graphics File Format






The original version of the GIF format was called 87a. In 1989, CompuServe devised an enhanced version, called 89a, 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, 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 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’ IPA: /ˈɡɪ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. Both pronunciations are given as correct by the Oxford English Dictionary and the American Heritage Dictionary.

  • 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 aren’t widely used.

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 exist 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 which was based on the common subset of the standard Windows and Macintosh palettes.[citation needed] This ensured predictable display but severely limited the choice of colors. Now that 24-bit graphics cards are the norm, optimized palettes make less sense when creating images, though some web designers still advise the use of the web safe palette.

There are at least two rarely-used methods 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.

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.

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.


In computing, JPEG (pronounced JAY-peg; IPA: /ˈdʒeɪpɛg/) is a commonly used method of compression for photographic images. The degree of compression can be adjusted, allowing a selectable tradeoff between storage size and image quality. JPEG typically achieves 10:1 compression with little perceptible loss in image quality.


The MIME media type for JPEG is image/jpeg (defined in RFC 1341).


The JPEG standard specifies both the codec, which defines how an image is compressed into a stream of bytes and decompressed back into an image, and the file format used to contain that stream.

The JPEG compression algorithm is at its best on photographs and paintings of realistic scenes with smooth variations of tone and color. For web usage, where the bandwidth used by an image is important, JPEG is very popular. And JPEG/Exif is the most common format saved by digital cameras.


As JPEG is a lossy compression method — it removes information from the image — it must not be used in astronomical or medical imaging or other purposes where the exact reproduction of the data is required. Lossless formats such as PNG must be used instead.

The compression method is usually lossy, meaning that some visual quality is lost in the process and cannot be restored. There are variations on the standard baseline JPEG that are lossless; however, these are not widely supported.

There is also an interlaced “Progressive JPEG” format, in which data is compressed in multiple passes of progressively higher detail. This is ideal for large images that will be displayed while downloading over a slow connection, allowing a reasonable preview after receiving only a portion of the data. However, progressive JPEGs are not as widely supported, and even some software which does support them (such as some versions of Internet Explorer) only displays the image once it has been completely downloaded.

There are also many medical imaging systems that create and process 12-bit JPEG images. The 12-bit JPEG format has been part of the JPEG specification for some time, but again, this format is not as widely supported.

A number of alterations to a JPEG image can be performed losslessly (that is, without recompression and the associated quality loss) as long as the image size is a multiple 1 MCU block (Minimum Coded Unit) (usually 16 pixels in both directions, for 4:2:0).


The top and left of a JPEG image must lie on a block boundary, but the bottom and right need not do so. This limits the possible lossless crop operations, and also what flips and rotates can be performed on an image whose edges do not lie on a block boundary for all channels.

When using lossless cropping, if the bottom or right side of the crop region is not on a block boundary then the rest of the data from the partially used blocks will still be present in the cropped file and can be recovered relatively easily by anyone with a hex editor and an understanding of the format.


The file format is known as ‘JPEG Interchange Format’ (JIF), as specified in Annex B of the standard. However, this “pure” file format is rarely used, primarily because of the difficulty of programming encoders and decoders that fully implement all aspects of the standard and because of certain shortcomings of the standard:

  • Color space definition
  • Component sub-sampling registration
  • Pixel aspect ratio definition


There is some confusion between the original ‘JPEG Interchange Format’ (JIF) and the similarly titled ‘JPEG File Interchange Format’ (JFIF). In some ways JFIF is a cutdown version of the JIF standard in that it specifies certain constraints (such as standard color space), while in other ways it is an extension of JIF due to the standard Application Segment header. The documentation for the original JFIF standard states:


Image files that employ JPEG compression are commonly called “JPEG files”. Most image capture devices (such as digital cameras) and most image editing software programs that write to a “JPEG file” are actually creating a file in the JFIF and/or Exif format.

Strictly speaking, the JFIF and Exif standards are incompatible because they each specify that their header appears first. In practice, most JPEG files in Exif format contain a small JFIF header that precedes the Exif header. This allows older readers to correctly handle the older format JFIF header, while newer readers also decode the following Exif header.


Many JPEG files embed an ICC color profile (color space). Commonly used color profiles include sRGB and Adobe RGB. Because these color spaces use a non-linear transformation, the dynamic range of an 8-bit JPEG file is about 11 stops. However, many applications are not able to deal with JPEG color profiles and simply ignore them.


Within the entropy-coded data, after any 0xFF byte, a 0x00 byte is inserted by the encoder before the next byte, so that there does not appear to be a marker where none is intended. Decoders must skip this 0x00 byte. This technique, called byte stuffing, is only applied to the entropy-coded data, not to marker payload data.

There are other Start Of Frame markers that introduce other kinds of JPEG.

Since several vendors might use the same APPn marker type, application-specific markers often begin with a standard or vendor name (e.g., “Exif” or “Adobe”) or some other identifying string.

At a restart marker, block-to-block predictor variables are reset, and the bitstream is synchronized to a byte boundary. Restart markers provide means for recovery after bitstream error. Since the runs of macroblocks between restart markers may be independently decoded, these runs may be decoded in parallel.


  1. The representation of the colors in the image is converted from RGB to YCbCr, consisting of one luma component (Y), representing brightness, and two chroma components, (Cb and Cr), representing color. This step is sometimes skipped.

The decoding process reverses these steps. In the remainder of this section, the encoding and decoding processes are described in more detail.


First, the image should be converted from RGB into a different color space called YCbCr. It has three components Y, Cb and Cr: the Y component represents the brightness of a pixel, the Cb and Cr components represent the chrominance (split into blue and red components). This is the same color space as used by digital color television as well as digital video including video DVDs, and is similar to the way color is represented in analog PAL video and MAC but not by analog NTSC, which uses the YIQ color space. The YCbCr color space conversion allows greater compression without a significant effect on perceptual image quality (or greater perceptual image quality for the same compression). The compression is more efficient as the brightness information, which is more important to the eventual perceptual quality of the image, is confined to a single channel, more closely representing the human visual system.

This conversion to YCbCr is specified in the JFIF standard, and should be performed for the resulting JPEG file to have maximum compatibility. However, some JPEG implementations in “highest quality” mode do not apply this step and instead keep the color information in the RGB color model[citation needed], where the image is stored in separate channels for red, green and blue luminance. This results in less efficient compression, and would not likely be used if file size was an issue.

Due to the densities of color- and brightness-sensitive receptors in the human eye, humans can see considerably more fine detail in the brightness of an image (the Y component) than in the color of an image (the Cb and Cr components). Using this knowledge, encoders can be designed to compress images more efficiently.

The transformation into the YCbCr color model enables the next step, which is to reduce the spatial resolution of the Cb and Cr components (called “downsampling” or “chroma subsampling“). The ratios at which the downsampling can be done on JPEG are 4:4:4 (no downsampling), 4:2:2 (reduce by factor of 2 in horizontal direction), and most commonly 4:2:0 (reduce by factor of 2 in horizontal and vertical directions). For the rest of the compression process, Y, Cb and Cr are processed separately and in a very similar manner.

After subsampling, each channel must be split into 8×8 blocks of pixels. If the data for a channel does not represent an integer number of blocks then the encoder must fill the remaining area of the incomplete blocks with some form of dummy data. Filling the edge pixels with a fixed color (typically black) creates ringing artifacts along the visible part of the border; repeating the edge pixels is a common technique that reduces the visible border, but it can still create artifacts.

The resulting compression ratio can be varied according to need by being more or less aggressive in the divisors used in the quantization phase. Ten to one compression usually results in an image that cannot be distinguished by eye from the original. 100 to one compression is usually possible, but will look distinctly artifacted compared to the original. The appropriate level of compression depends on the use to which the image will be put.

Those who use the World Wide Web may be familiar with the irregularities known as compression artifacts (commonly known as ‘jaggies’) that appear in JPEG images. These are due to the quantization step of the JPEG algorithm. They are especially noticeable around sharp corners between contrasting colours (text is a good example as it contains many such corners). They can be reduced by choosing a lower level of compression; they may be eliminated by saving an image using a lossless file format, though for photographic images this will usually result in a larger file size. Compression artifacts make low-quality JPEGs unacceptable for storing heightmaps. The images created with ray-tracing programs have noticeable blocky shapes on the terrain.




For information, the uncompressed 24-bit RGB bitmap image below (73,242 pixels) would require 219,726 bytes (excluding all other information headers). The filesizes indicated below include the internal JPEG information headers and some meta-data. For full quality images (Q=100), about 8.25 bits per color pixel is required. On grayscale images, a minimum of 6.5 bits per pixel is enough (a comparable Q=100 quality color information requires about 25% more encoded bits). The full quality image below (Q=100) is encoded at 9 bits per color pixel, the medium quality image (Q=25) uses 1 bit per color pixel. For most applications, the quality factor should not go below 0.75 bit per pixel (Q=12.5), as demonstrated by the low quality image. The image at lowest quality uses only 0.13 bit per pixel, and displays very poor color, it could only be usable after subsampling to a much lower display size.

The medium quality photo uses only 4.3% of the storage space but has little noticeable loss of detail or visible artifacts. However, once a certain threshold of compression is passed, compressed images show increasingly visible defects. See the article on rate distortion theory for a mathematical explanation of this threshold effect.

From 2004 to 2008, new research has emerged on ways to further compress the data contained in JPEG images without modifying the represented image. This has applications in scenarios where the original image is only available in JPEG format, and its size needs to be reduced for archival or transmission. Standard general-purpose compression tools cannot significantly compress JPEG files.


  • Correlations between magnitudes of adjacent coefficients in the same block;
  • Correlations between magnitudes of the same coefficient in adjacent blocks;

Some standard but rarely-used options already exist in JPEG to improve the efficiency of coding DCT coefficients: the arithmetic coding option, and the progressive coding option (which produces lower bitrates because values for each coefficient are coded independently, and each coefficient has a significantly different distribution). Modern methods have improved on these techniques by reordering coefficients to group coefficients of larger magnitude together; using adjacent coefficients and blocks to predict new coefficient values; dividing blocks or coefficients up among a small number of independently coded models based on their statistics and adjacent values; and most recently, by decoding blocks, predicting subsequent blocks in the spatial domain, and then encoding these to generate predictions for DCT coefficients.


A freely-available tool called PackJPG is based on the 2007 paper “Improved Redundancy Reduction for JPEG Files.” There are also at least two companies selling proprietary tools with similar capabilities, Infima’s JPACK and Allume’s StuffIt Deluxe, both of which claim to have pending patents on their respective undisclosed technologies.

In 2002 Forgent Networks asserted that it owned and would enforce patent rights on the JPEG technology, arising from a patent that had been filed on October 27, 1986, and granted on October 6, 1987 (U.S. Patent 4,698,672 ). The announcement created a furor reminiscent of Unisys‘ attempts to assert its rights over the GIF image compression standard.

The JPEG committee investigated the patent claims in 2002 and were of the opinion that they were invalidated by prior art. Others also concluded that Forgent did not have a patent that covered JPEG. Nevertheless, between 2002 and 2004 Forgent was able to obtain about US$105 million by licensing their patent to some 30 companies. In April 2004, Forgent sued 31 other companies to enforce further license payments. In July of the same year, a consortium of 21 large computer companies filed a countersuit, with the goal of invalidating the patent. In contrast to other major computer companies such as Sony and Philips, Microsoft launched a major lawsuit against Forgent. In February 2006, the United States Patent and Trademark Office agreed to re-examine Forgent’s JPEG patent at the request of the Public Patent Foundation. On May 26, 2006 the USPTO found the patent invalid based on prior art. The USPTO also found that Forgent knew about the prior art, and did not tell the Patent Office, making any appeal to reinstate the patent highly unlikely to succeed.


As of October 27, 2006, the U.S. patent’s 20-year term appears to have expired, and in November 2006, Forgent agreed to abandon enforcement of patent claims against use of the JPEG standard.

The JPEG committee has as one of its explicit goals that their standards (in particular their baseline methods) be implementable without payment of license fees, and they have secured appropriate license rights for their upcoming JPEG 2000 standard from over 20 large organizations.

Beginning in August 2007, another company, Global Patent Holdings, LLC claimed that its patent (U.S. Patent 5,253,341 ), is infringed by the downloading of JPEG images on either a website or through e-mail. If not invalidated, this patent could apply to any website that displays JPEG images. The patent emerged in July 2007 following a seven-year reexamination by the U.S. Patent and Trademark Office in which all of the original claims of the patent were revoked, but an additional claim (claim 17) was confirmed. In its first two lawsuits following the reexamination, both filed in Chicago, Illinois, Global Patent Holdings sued the Green Bay Packers, CDW, Motorola, Apple, Orbitz, Officemax, Caterpillar, Kraft and Peapod as defendants. A third lawsuit was filed on December 5, 2007 in Southern Florida against ADT Security Services, AutoNation, Florida Crystals Corp., HearUSA, MovieTickets.com, Ocwen Financial Corp. and Tire Kingdom, and a fourth lawsuit on January 8, 2008 in Southern Florida against the Boca Raton Resort & Club. A fifth lawsuit was filed against Global Patent Holdings in Nevada. That lawsuit was filed by Zappos.com, Inc., who was allegedly threatened by Global Patent Holdings, and seeks a judicial declaration that the ‘341 patent is invalid and not infringed. The patent owner has also used the patent to sue or threaten outspoken critics of broad software patents, including Gregory Aharonian and the anonymous operator of a website blog known as the “Patent Troll Tracker.” On December 21, 2007, patent lawyer Vernon Francissen of Chicago asked the U.S. Patent and Trademark Office to reexamine the sole remaining claim of the ‘341 patent on the basis of new prior art. On March 5, 2008, the U.S. Patent and Trademark Office agreed to reexamine the ‘341 patent, finding that the new prior art raised substantial new questions regarding the patent’s validity. In light of the reexamination, the accused infringers in four of the five pending lawsuits have filed motions to suspend (stay) their cases until completion of the U.S. Patent and Trademark Office’s review of the ‘341 patent. On April 23, 2008, a judge presiding over the two lawsuits in Chicago, Illinois granted the motions in those cases. On July 22, 2008, the Patent Office issued the first “Office Action” of the second reexamination, finding the claim invalid based on nineteen separate grounds.

  • JPEG (lossy and lossless): ITU-T T.81, ISO/IEC IS 10918-1
  • JPEG (extensions): ITU-T T.84
  • JPEG-LS (lossless, improved): ITU-T T.87, ISO/IEC IS 14495-1
  • JBIG (black and white pictures): ITU-T T.82, ISO/IEC IS 11544-1
  • JPEG 2000 (successor of JPEG/JPEG-LS): ITU-T T.800, ISO/IEC IS 15444-1
  • JPEG-2000 (extensions): ITU-T T.801
  • JPEG XR (formerly called HD Photo) undergoing final voting as ISO/IEC 29199-2

3. PNG



PNG files nearly always use file-extension “PNG” or “png” and are assigned MIME media type “image/png” (approved October 14, 1996).

The motivation for creating the PNG format came in early 1995 when it came to light that the LZW data compression algorithm used in the GIF format had been patented by Unisys. For more on this controversy see GIF (Unisys and LZW patent enforcement). There were also other problems with the GIF format which made a replacement desirable, notably its limitation to 256 colors at a time when computers capable of displaying far more than 256 colors were becoming common. Although GIF allows for animation, it was decided that PNG should be a single-image format. A companion format called MNG (Multi-image Network Graphics) has been defined for animation.

A precursory discussion thread on newsgroup “comp.graphics” with the subject Thoughts on a GIF-replacement file format, dating back to January 1995 has many propositions which would later be part of the PNG file format, and displays Oliver Fromme, author of the popular MS-DOS JPEG viewer QPEG, proposing the PING name meaning PING is not GIF, and also the PNG extension for the first time.






The case of the second letter indicates if the chunk is “public” (either in the specification or the registry of special purpose public chunks) or “private” (not standardised). Uppercase is public and lowercase is private. This ensures that public and private chunk names can never conflict with each other (although two private chunk names could conflict).




  • PLTE contains the palette; list of colors.
  • IEND marks the image end.



  • cHRM gives the white balance.
  • gAMA specifies gamma.
  • iCCP is an ICC color profile.
  • sRGB indicates that the standard sRGB color space is used.
  • tIME stores the time that the image was last changed.
  • zTXt contains compressed text with the same limits as tEXt.




  • indexed (channel containing indexes into a palette of colors)
  • greyscale
  • greyscale and alpha (level of transparency for each pixel)
  • red, green and blue (rgb/truecolor)
  • red, green, blue and alpha






PNG offers an optional 2-dimensional, 7-pass interlacing scheme – the Adam7 algorithm. This is more sophisticated than GIF’s 1-dimensional, 4-pass scheme, and allows a clearer low-resolution image to be visible earlier in the transfer. However, as a 7-pass scheme, it tends to reduce the data’s compressibility more than simpler schemes.

PNG itself does not support animation at all. MNG is an extension to PNG that does; it was designed by members of the PNG Group. MNG shares PNG’s basic structure and chunks, but it is significantly more complex and has a different file signature, which automatically renders it incompatible with standard PNG decoders.



Other popular graphics programs which support the PNG format include Adobe Photoshop, Corel Photo-Paint, Corel PaintShop Pro, The GIMP, GraphicConverter, Helicon Filter, Inkscape, Jasc Paint Shop Pro (Corel), Pixel image editor, Paint.NET and Xara. Some programs bundled with popular operating systems which support PNG include Microsoft’s Paint and Apple’s iPhoto and Preview.


  • Microsoft’s Paint for Windows XP
  • Microsoft Picture It! Photo Premium 9
  • older versions of Adobe Photoshop.


PNG support first appeared in Internet Explorer 4.0b1 and in Netscape 4.04.

Despite calls by the Free Software Foundation and the w3c, tools such as gif2png, and campaigns such as burn all gifs, PNG adoption on websites has been fairly slow.


  • No animation, still images only (unlike GIF, though Mozilla’s unofficial APNG format is a potential solution).

PNG compatible browsers include: Apple Safari, Google Chrome, Mozilla Firefox, Opera, Camino, Internet Explorer 7, and many others. For the complete comparison, see Comparison of web browsers (Image format support).

However, Internet Explorer (Windows), before version 7, has a fair share of issues, which prevent it from using PNG to its full potential.

PNG icons have been supported in most distributions of Linux since at least 1999, in desktop environments such as GNOME. In 2006, Microsoft introduced PNG icons into Windows with the release of Windows Vista. PNG icons are supported in Mac OS X as well. Another operating system to include 3rd party PNG icons support is AmigaOS 3/4 (and its clones – MorphOS and AROS).


As GIF is limited to 256 colors, many image editors will automatically reduce the color depth when saving an image in GIF format. Often when people save the same truecolor image as PNG and GIF, they see that the GIF is smaller, and do not realise it is possible to create a 256 color PNG that has identical quality to the GIF with a smaller file size. This leads to the misconception that PNG files are larger than equivalent GIF files.

In practice, well optimized and compressed PNG files are usually much smaller than GIF files (10 % to 50 % savings) for filesizes above about 100 bytes.[citation needed]

Some versions of Adobe Photoshop, CorelDRAW and MS Paint provide poor PNG compression effort, further fueling the idea that PNG is larger than GIF. Many graphics programs (such as Apple’s Preview software) save PNGs with large amounts of metadata and color-correction data that are generally unnecessary for Web viewing. Unoptimized PNG files from Adobe Fireworks are also notorious for this.

It should be noted that Adobe Photoshop‘s performance on PNG files has been much improved in the CS Suite when using the Save For Web feature (which also allows explicit PNG/8 use).

Various tools are available for optimizing PNG files. OptiPNG and pngcrush are both open-source software optimizers that run from a Unix command line or a Windows Command Prompt, and effectively reduce the size of PNG files. The littleutils is another open-source package that contains a wrapper script called opt-png. This script utilizes pngcrush and a variant of pngrewrite to reduce bit-depth when possible, reducing PNG file sizes further. Perl scripts might wish to employ Image-Pngslimmer which allows some dynamic optimization.

Other tools such as AdvanceCOMP and Ken Silverman‘s PNGOUT are capable of reducing the file size even further still, giving the competent user the smallest file size possible for a given PNG image. The current version of IrfanView can use PNGOUT as an external plug-in, and the screenshots show PNGOUT’s save options.



There’s GUI front-end for OptiPNG, pngcrush and advpng that runs on Mac OS X.




The phrases “Tagged Image File Format” and “Tag Image File Format” were used as the subtitle to some early versions of the TIFF specification; the current specification, TIFF 6.0, does not use either subtitle phrase; the name is now, simply, “TIFF”.




The TIFF offers the option of using LZW compression, a lossless data-compression technique for reducing a file’s size. Until 2004, this option’s use was limited, because the LZW technique then was under several patents; however, these patents are expired.

Every TIFF begins with a 2-byte indicator of byte order: “II” for little endian and “MM” for big endian byte ordering. The next 2 bytes represent the number 42, selected “for its deep philosophical significance“. The 42-reading depends upon the byte order indicated by the 2-byte indicator. All words, double words, etc., in the TIFF file are read based per the indicated byte order. The TIFF 6.0 Specification (Section 7: Additional baseline TIFF Requirements) says that compliant TIFF readers must support both byte orders (II and MM), however, TIFF writers may choose the byte order convenient for their image. The image-processing community’s joke about the early TIFF’s standardised-consistency problems is Thousands of Incompatible File Formats.



The TIFF format can save multi-page documents to a single TIFF file rather than a series of files for each scanned page. Multi-page support and 2D compression of bitonal images led to the TIFF’s becoming the standard storage format for facsimiles, especially on Fax Servers.



Developers can apply for a block of “private tags” to enable them to include their own proprietary information inside a TIFF file without causing problems for file interchange. TIFF readers are required to ignore tags that they do not recognize, and a developer’s private tags are guaranteed not to clash with anyone else’s tags or with the standard set of tags defined in the specification.



5. BMP

The BMP file format, sometimes called bitmap or DIB file format (for device-independent bitmap), is an image file format used to store bitmap digital images, especially on Microsoft Windows and OS/2 operating systems.

Many graphical user interfaces use bitmaps in their built-in graphics subsystems; for example, the Microsoft Windows and OS/2 platforms’ GDI subsystem, where the specific format used is the Windows and OS/2 bitmap file format, usually named with the file extension of .BMP or .DIB.

In uncompressed BMP files, and many other bitmap file formats, image pixels are stored with a color depth of 1, 4, 8, 16, 24, or 32 bits per pixel. Images of 8 bits and fewer can be either grayscale or indexed color. An alpha channel (for transparency) may be stored in a separate file, where it is similar to a grayscale image, or in a fourth channel that converts 24-bit images to 32 bits per pixel.

Uncompressed bitmap files (such as BMP) are typically much larger than compressed (with any of various methods) image file formats for the same image. For example, the 1058×1058 Wikipedia logo, which occupies about 287.65 KB in the PNG format, takes about 3358 KB as a 24-bit BMP file. Uncompressed formats are generally unsuitable for transferring images on the Internet or other slow or capacity-limited media.

The bits representing the bitmap pixels are packed within rows. Depending on the color depth, a pixel in the picture will occupy at least n/8 bytes (n is the bit depth, since 1 byte equals 8 bits). The approximate size for a n-bit (2n colors) BMP file in bytes can be calculated, including the effect of starting each word on a 32-bit dword boundary, as:

\mbox{rowsize} = 4 \cdot \Big\lfloor\frac {(n \cdot \mbox{width}) + 31}{32}\Big\rfloor, where the floor function gives the highest integer that is less than or equal to the argument; that is, the number of 32-bit dwords needed to hold a row of n-bit pixels; this value multiplied by 4 gives the byte count.
\mbox{filesize} \approx 54 + 4 \cdot 2^n + \mbox{rowsize} \cdot \mbox{height}, where height and width are given in pixels.

In the formula above, 54 is the size of the headers in the popular Windows V3 BMP version (14-byte BMP file header plus 40-byte DIB V3 header); some other header versions will be larger or smaller than that, as described in tables below. And 4 \cdot 2^n is the size of the color palette; this size is an approximation, as the color palette size will be 3 \cdot 2^n bytes in the OS/2 V1 version, and some other versions may optionally define only the number of colors needed by the image, potentially fewer than 2n. Only files with 8 or fewer bits per pixel use a palette; for 16-bit (or higher) bitmaps, omit the palette part from the size calculation:

\mbox{filesize} \approx 54 + \mbox{rowsize} \cdot \mbox{height}

For detailed information, see the sections on file format below.

Microsoft has defined a particular representation of color bitmaps of different color depths, as an aid to exchanging bitmaps between devices and applications with a variety of internal representations. They called these device-independent bitmaps or DIBs, and the file format for them is called DIB file format or BMP file format. According to Microsoft support:

Since BMP/DIB format was created for the Intel X86 architecture, all integers are stored in little-endian format.


A typical BMP file usually contains the following blocks of data:

The following sections discuss the data stored in the BMP file or DIB in details. This is the standard BMP file format. Some bitmap images may be stored using a slightly different format, depending on the application that creates it. Also, not all fields are used; a value of 0 will be found in these unused fields.

A BMP file is loaded into memory as a DIB data structure, an important component of the Windows GDI API. The DIB data structure is the same as the BMP file format, but without the 14-byte BMP header.

This block of bytes is at the start of the file and is used to identify the file. A typical application reads this block first to ensure that the file is actually a BMP file and that it is not damaged. Note that the first two bytes of the BMP file format (thus the BMP header) are stored in big-endian order. This is the magic number ‘BM’. All of the other integer values are stored in little-endian format (i.e. least-significant byte first).

This block of bytes tells the application detailed information about the image, which will be used to display the image on the screen. The block also matches the header used internally by Windows and OS/2 and has several different variants. All of them contain a dword field, specifying their size, so that an application can easily determine which header is used in the image. The reason that there are different headers is that Microsoft extended the DIB format several times. The new extended headers can be used with some GDI functions instead of the older ones, providing more functionality. Since the GDI supports a function for loading bitmap files, typical Windows applications use that functionality. One consequence of this is that for such applications, the BMP formats that they support match the formats supported by the Windows version being run. See the table below for more information.

For compatibility reasons, most applications use the older DIB headers for saving files. With OS/2 being obsolete, for now the only common format is the V3 header. See next table for its description. All values are stored as unsigned integers, unless explicitly noted.

A 32-bit version of DIB with integrated alpha channel has been introduced with Windows XP and is used within its logon and theme system; it has yet to gain wide support in image editing software, but has been supported in Adobe Photoshop since version 7 and Adobe Flash since version MX 2004 (then known as Macromedia Flash).

The palette occurs in the BMP file directly after the BMP header and the DIB header. Therefore, its offset is the size of the BMP header plus the size of the DIB header.

The palette is a block of bytes (a table) listing the colors available for use in a particular indexed-color image. Each pixel in the image is described by a number of bits (1, 4, or 8) which index a single color in this table. The purpose of the color palette in indexed-color bitmaps is to tell the application the actual color that each of these index values corresponds to.

A DIB always uses the RGB color model. In this model, a color is terms of different intensities (from 0 to 255) of the additive primary colors red (R), green (G), and blue (B). A color is thus defined using the 3 values for R, G and B (though stored in backwards order in each palette entry).

The number of entries in the palette is either 2n or a smaller number specified in the header (in the OS/2 V1 format, only the full-size palette is supported). Each entry contains four bytes, except in the case of the OS/2 V1 versions, in which case there are only three bytes per entry. The first (and only for OS/2 V1) three bytes store the values for blue, green, and red, respectively, while the last one is unused and is filled with 0 by most applications.

As mentioned above, the color palette is not used when the bitmap is 16-bit or higher; there are no palette bytes in those BMP files.

This block of bytes describes the image, pixel by pixel. Pixels are stored “upside-down” with respect to normal image raster scan order, starting in the lower left corner, going from left to right, and then row by row from the bottom to the top of the image. Uncompressed Windows bitmaps can also be stored from the top row to the bottom, if the image height value is negative.

In the original DIB, the only four legal numbers of bits per pixel are 1, 4, 8, and 24. In all cases, each row of pixels is extended to a 32-bit (4-byte) boundary, filling with an unspecified value (not necessarily 0) so that the next row will start on a multiple-of-four byte location in memory or in the file. The total number of bytes in a row can be calculated as the image size/bitmap height in pixels. Following these rules there are several ways to store the pixel data depending on the color depth and the compression type of the bitmap.

One-bit (two-color, for example, black and white) pixel values are stored in each bit, with the first (left-most) pixel in the most-significant bit of the first byte. An unset bit will refer to the first color table entry, and a set bit will refer to the last (second) table entry.

Four-bit color (16 colors) is stored with two pixels per byte, the left-most pixel being in the more significant nibble. Each pixel value is an index into a table of up to 16 colors.

Eight-bit color (256 colors) is stored one pixel value per byte. Each byte is an index into a table of up to 256 colors.

RGB color (24-bit) pixel values are stored with bytes in the same order (blue, green, red) as in the color table.

The simplicity of the BMP file format, and its widespread familiarity in Windows and elsewhere, as well as the fact that this format is relatively well documented and free of patents, makes it a very common format that image processing programs from many operating systems can read and write.

While most BMP files have a relatively large file size due to lack of any compression, many BMP files can be considerably compressed with lossless data compression algorithms such as ZIP (up to 0.1% of original size) because they contain redundant data.

The X Window System uses a similar XBM format for black-and-white images, and XPM (pixelmap) for color images. There are also a variety of “raw” formats, which saves raw data with no other information. The Portable Pixmap (PPM) and Truevision TGA formats also exist, but are less often used – or only for special purposes; for example, TGA can contain transparency information.

Numerous other bitmap file formats are in use, though most not widely.



Early versions of the AI file format are true EPS files with a restricted, compact syntax, with additional semantics represented by Illustrator-specific DSC comments that conform to DSC’s Open Structuring Conventions. These files are identical to their corresponding Illustrator EPS counterparts, but with the EPS procsets (procedure sets) omitted from the file and instead externally referenced using %%Include directives.

Recent versions of the AI file format, including the PDF-based formats and recent EPS formats, are based on a native format called PGF that is unrelated to both EPS and PDF. PDF compatibility is achieved not by extending the PDF format, but by embedding a complete copy of the native PGF data within the PDF file. The same kind of “dual path” approach is also used when recent versions of Illustrator are saving EPS-compatible files.

Adobe Illustrator is not the only program that can edit .ai files. Both Inkscape (a GPL licensed program) and CorelDRAW (another Proprietary program) can natively edit this file format.

7. AutoCAD DXF

AutoCAD DXF (Drawing Interchange Format, or Drawing Exchange Format) is a CAD data file format developed by Autodesk[citation needed] for enabling data interoperability between AutoCAD and other programs.

DXF was originally introduced in December 1982 as part of AutoCAD 1.0, and was intended to provide an exact representation of the data in the AutoCAD native file format, DWG (Drawing), for which Autodesk for many years did not publish specifications. Because of this, correct imports of DXF files have been difficult. Autodesk now publishes the DXF specifications, http://usa.autodesk.com/adsk/servlet/item?siteID=123112&id=8446698 on its website for versions of DXF dating from AutoCAD Release 13 to AutoCAD 2009.


As AutoCAD has become more powerful, supporting more complex object types, DXF has become less useful. Certain object types, including ACIS solids and regions, are not documented. Other object types, including AutoCAD 2006’s dynamic blocks, and all of the objects specific to the vertical-market versions of AutoCAD, are partially documented, but not well enough to allow other developers to support them. For these reasons many CAD applications use the DWG format which can be licensed from AutoDesk or non-natively from the Open Design Alliance.


  • TABLES section – This section contains definitions of named items.
Application ID (APPID) table
Block Recod (BLOCK_RECORD) table
Dimension Style (DIMSTYPE) table
Layer (LAYER) table
Linetype (LTYPE) table
Text style (STYLE) table
User Coordinate System (UCS) table
View (VIEW) table
Viewport configuration (VPORT) table

8. CGM

Computer Graphics Metafile (CGM) is a free and open international standard file format for 2D vector graphics, raster graphics, and text, and is defined by ISO/IEC 8632.

All graphical elements can be specified in a textual source file that can be compiled into a binary file or one of two text representations. CGM provides a means of graphics data interchange for computer representation of 2D graphical information independent from any particular application, system, platform, or device. As a metafile, i.e. a file containing information that describes or specifies another file, the CGM format has numerous elements to provide functions and to represent entities, so that a wide range of graphical information and geometric primitives can be accommodated. Rather than establish an explicit graphics file format, CGM contains the instructions and data for reconstructing graphical components to render an image using an object-oriented approach.

Although CGM is not widely supported for web pages and has been supplanted by other formats in the graphic arts, it is still prevalent in engineering, aviation, and other technical applications.

The initial CGM implementation was effectively a streamed representation of a sequence of Graphical Kernel System primitive operations. It has been adopted to some extent in the areas of technical illustration and professional design, but has largely been superseded by formats such as SVG and DXF.

The World Wide Web Consortium has developed WebCGM, a profile of CGM intended for the use of CGM on the Web.

  • 1986 – ANSI X3 122-1986 (ANSI X3 committee)
  • 1987 – ISO 8632-1987 (ISO)
  • 1991 – ANSI/ISO 8632-1987 (ANSI and ISO)
  • 1992 – ISO 8632:1992, a.k.a CGM:1992 (ISO)
  • 1999 – ISO/IEC 8632:1999, 2nd Edition (ISO/IEC JTC1/SC24)
  • December 17, 2001 – WebCGM (W3C)
  • January 30, 2007 – WebCGM 2.0 (W3C)
  • Arnold, D.B. and P.R. Bono, CGM and CGI: Metafile and Interface Standards for Computer Graphics, Springer-Verlag, New York, NY, 1988.
  • Henderson, L.R., and Gebhardt, “CGM: SGML for Graphics,” The Gilbane Report, Fall 1994.
  • Henderson, L.R., and A.M. Mumford, The CGM Handbook, Academic Press, San Diego, CA, 1993.
  • Bono, P.R. , J.L. Encarnacao, L.M. Encarnacao, and W.R. Herzner, PC Graphics With GKS, Prentice-Hall, Englewood Cliffs, NJ, 1990.

9. MIF

Maker Interchange Format (MIF) is a proprietary markup language associated with Adobe SystemsFrameMaker product for technical document preparation.

While MIF is essentially specific to a single program (FrameMaker), it was widely used in the complex document workflows of small enterprises, especially in the industrial and manufacturing sector.

10. SVG





SVG has been in development since 1999 by a group of companies within the W3C after the competing standards PGML (developed from Adobe’s PostScript) and VML (developed from Microsoft’s RTF) were submitted to W3C in 1998. SVG drew on experience designing both those formats.

SVG allows three types of graphic objects:


While being primarily designated as a vector graphics markup language, the specification is also designed with the basic capabilities of a page description language, like Adobe’s PDF. It contains provisions for rich graphics, and is also compatible with the CSS specification’s properties for styling purposes; thus, unlike XHTML and XSL-FO which are layout-oriented languages, SVG is a fully presentational language. A much more print-specialized subset of SVG (SVG Print, authored by Canon, HP, Adobe and Corel) is currently a W3C Working Draft.


SVG images, being XML, contain many repeated fragments of text and are thus particularly suited to compression by gzip, though other compression methods may be used effectively. Once an SVG image has been compressed by gzip it may be referred to as an “SVGZ” image; with the corresponding filename extension. The resulting file may be as small as 20% of the original size.


    • SVG Tiny and SVG Basic (the Mobile SVG Profiles) became W3C Recommendations on January 14, 2003. These are described as profiles of SVG 1.1.
  • SVG Tiny 1.2 became a W3C Recommendation on December 22, 2008.
  • SVG Print adds syntax for multi-page documents and mandatory color management support.




SVGT 1.2 adds a microDOM (μDOM), allowing all mobile needs to be met with a single profile.

The SVG 1.1 specification defines 14 important functional areas or feature sets:

Basic Shapes
Straight-line paths or paths made up of a series of connected straight-line segments (polylines), as well as closed polygons, circles and ellipses can be drawn. Rectangles and round-cornered “rectangles” are other standard elements.
SVG shapes can be filled and/or outlined (painted with a color, a gradient or a pattern). Fills can be opaque or have various degrees of transparency. “Markers” are end-of-line features, such as arrowheads, or symbols which can appear at the vertices of a polygon.
Colors can be applied to all visible SVG elements, either directly or via the ‘fill’, ‘stroke’ and other properties. Colors are specified in the same way as in CSS2, i.e. using names like black or blue, in hexadecimal such as #2f0 or #22ff00, in decimal like rgb(255,255,127) or as percentages of the form rgb(100%,100%,50%).
Gradients and Patterns
Clipping, Masking and Compositing
Graphic elements, including text, paths, basic shapes and combinations of these, can be used as outlines to define both ‘inside’ and ‘outside’ regions that can be painted (with colors, gradients and patterns) independently. Fully opaque clipping paths and semi-transparent masks are composited together to calculate the color and opacity of every pixel of the final image, using simple alpha blending.


There are several advantages to native support: plugins would not need to be installed, SVG could be freely mixed with other formats in a single document, and rendering scripting between different document formats would be considerably more reliable. At this time all major browsers have committed to some level of SVG support except for Internet Explorer which will also not support SVG in the upcoming version IE8. Other browsers’ implementations are not yet fully functional. See Comparison of layout engines for further details. As of 2008[update], only Opera and Safari support embedding via the <img> tag. Tim Berners-Lee, the inventor of the Web, has been critical of Internet Explorer for its failure to support SVG.

  • Opera (since 8.0) has support for the SVG 1.1 Tiny specification while Opera 9 includes SVG 1.1 Basic support and some of SVG 1.1 Full. Since 9.5 Opera has partial SVG Tiny 1.2 support.
  • Browsers based on WebKit (such as Apple‘s Safari, Google Chrome, and The Omni Group‘s OmniWeb) have incomplete support for the SVG 1.1 Full specification since 2006. This includes Safari 3.0 and later (included with Mac OS X v10.5 and Mac OS X v10.4.11) as well as Mobile Safari as of iPhone OS 2.1.
  • Amaya has partial SVG support.

As of October 2008[update], Windows Internet Explorer provides no native SVG support. IE requires a plugin to render SVG content.





  • Inkscape is a free software SVG drawing program for Linux, Microsoft Windows and Mac OS X.
  • xfig allows import and export of SVG drawings.
  • OpenOffice.org Draw can export SVG drawings. Import extensions are available to import SVG images into OpenOffice.org Draw.
  • Go-oo Draw (OpenOffice.org variant) can open and export SVG files.
  • OxygenOffice Draw (OpenOffice.org variant) can open and export SVG files.
  • CorelDRAW has an SVG export and import filter.
  • Blender will import SVG graphics as paths.
  • Altsoft Xml2PDF allows converting SVG files to PDF, PS, various GDI+ formats.




Nokia’s S60 platform has built-in support for SVG. For example, icons are generally rendered using the platform’s SVG engine. Nokia has also led the JSR 226: Scalable 2D Vector Graphics API expert group which defines Java ME API for SVG presentation and manipulation. This API has been implemented in S60 Platform 3rd Edition Feature Pack 1 onward. Some Series 40 phones also support SVG (such as 6280).



11. WMF


Essentially, a WMF file stores a list of function calls that have to be issued to the Windows graphics layer GDI in order to display an image on screen. Since some GDI functions accept pointers to callback functions for error handling, a WMF file may include executable code.

WMF is a 16-bit format introduced in Windows 3.0. It is the native vector format for Microsoft Office applications such as Word, PowerPoint, and Publisher. A newer 32-bit version with additional commands is called Enhanced Metafile (EMF). EMF is also used as a graphics language for printer drivers.

There are also compressed versions of Windows Metafiles known as Compressed Windows Metafile (WMZ) & Compressed Windows Enhanced Metafile (EMZ).

As for other Microsoft file formats, no specification of the format was previously available, and alternative implementations had to reverse engineer existing WMF files, which was difficult and error prone. In September 2006, Microsoft published the WMF file format specification in the context of the Microsoft Open Specification Promise, promising to not assert patent rights to file formats implementors.

In December 2005, a vulnerability was reported to Microsoft by Symantec. It was assessed and classified as critical. In certain cases, the graphics rendering engine allowed remote code execution. This vulnerability was resolved in a security update on January 5, 2006 on Microsoft TechNet (MS06-001) and generally released January 10, 2006. Details can be found in Microsoft Knowledge Base Article “Vulnerability in Graphics Rendering Engine Could Allow Remote Code Execution” (912919). It was also referred to as the WMF (Windows Meta File) vulnerability.

The WMF format was designed to be executed by the Windows graphics layer GDI in order to restore the image, but as the WMF binary files contain the definition of the GDI graphic primitives that constitute this image, it is possible to design alternative libraries that render WMF binary files, or convert them in other graphic formats.

For example, the Batik library is able to render WMF files and convert them to their SVG equivalent. The Vector Graphics package of the FreeHEP Java library allows the saving of Java2D drawings as EMF files.

EMZ is gzipped EMF. One program that directly unpacks EMZ and WMZ files into EMF and WMF files is SpeedCommander 12.


Leave a Reply


WordPress.com Logo


Twitter picture


Facebook photo


Google+ photo


Connecting to %s

%d bloggers like this: