B Image File and Compression Formats

B.1 Image File Formats

Image file formats are listed alphabetically.

BMPF

extension: .bmp

mime: image/bmp

BMPF is the Microsoft Windows bitmap format and is based on the internal data structures used by Windows to store bitmap data in memory. This format is used extensively by Microsoft Windows, and a variant of this format is used by the IBM OS/2 operating system. Because this format is supported directly by Windows, its use is very popular in that environment and has spread to other systems.

BMPF is a very flexible image format in that it can store a wide variety of image data types, but it does not offer powerful compression. The only compression available is a run-length encoding variant that is supported only by certain content formats. It is worth noting that BMPF is unusual in that the ordinary scanline order for this format is bottom-up, which Oracle interMedia calls INVERSE.

CALS

extension: .cal

mime: image/x-ora-cals

CALS is an image format for document interchange developed by the Computer-Aided Acquisition and Logistics Support office of the United States government. There are actually two variants of the CALS image format; interMedia supports CALS Type I. Because the CALS format is monochrome-only, it is primarily useful for storing simple documents, scanned or otherwise.

DICM

extension: .dcm

mime: application/dicom

DICM is the interMedia designation for the Digital Imaging and Communications in Medicine (DICOM) format. DICOM images are medical images that conform to the DICOM standard. DICOM image characteristics include a large number of embedded metadata attributes, arbitrary bit depth, multiple pixel ordering schemes, rich pixel compression codecs, and multiple pixel planes.

Foreign Images

Foreign images are images for which interMedia does not provide native recognition and support, but that can sometimes be read if the image data complies with the rules outlined in Section E.10, "Foreign Image Support and the Raw Pixel Format" in Appendix E.

FPIX

extension: .fpx

mime: image/x-fpx

FPIX, or FlashPix, is a format developed by Kodak, Microsoft Corporation, Hewlett-Packard Company, and Live Picture, Inc., for storing digital photography. FlashPix images are composed of a series of different resolutions of the same image, and each resolution is composed of individual tiles. These tiles can be uncompressed or compressed using JPEG. The multi-resolution capability of FlashPix images is intended to promote easy use in a wide variety of applications by allowing low resolution versions of the image to be used where high resolution versions are not necessary (such as browsing, viewing on screen), while high resolution versions are available when needed (printing or zooming in on an image detail).

Oracle interMedia includes a simple FlashPix decoder that always selects the largest resolution plane in a FlashPix image. Lower resolutions are not accessible. Oracle interMedia does not write FlashPix images.

GIFF

extension: .gif

mime: image/gif

GIFF is the interMedia name for the Graphics Interchange Format (GIF), which was developed by CompuServe to transfer images between users in their early network system. Because GIF (pronounced "jif") is an early format and was developed for use on limited hardware, it does not support content formats that store more than 8 bits per pixel. This makes the format less suitable for storing photographic or photo-realistic images than deeper formats such as PNG or JFIF, but it is a good choice for other applications. There are two specific variants of the GIF format, called 87a and 89a; interMedia reads both variants but writes the 87a variant.

Despite its pixel depth limitations, the GIF format remains a powerful and flexible image format, and includes support for limited transparency effects and simple animations by encoding a series of image frames and frame transition effects. interMedia can read GIF images that include these options but only the first frame of an animated GIF image is made available, and there is no support for writing animated GIF images.

All GIF images are compressed using a GIF-specific LZW compression scheme, which interMedia calls GIFLZW.

JFIF

extension: .jpg

mime: image/jpeg

JFIF is the JPEG File Interchange Format, developed by C-Cube Microsystems for storing JPEG encoded images. The JFIF format is actually just a JPEG data stream with an identifying header and a few enforced conventions. As such, it provides minimal support for anything but the actual image data. By definition, all JFIF files are JPEG compressed, making them less appropriate for some applications, as explained in the description of the JPEG compression format in Image Compression Formats.

Oracle interMedia identifies several distinct image formats as JFIF, including actual JFIF files, non-JFIF pure JPEG data streams, and EXIF files. The last is a JFIF variant produced by digital cameras.

PBMF, PGMF, PPMF, and PNMF

extension: .pbm, .pgm, .ppm, .pnm

mime: image/x-portable-bitmap, image/x-portable-graymap, image/x-portable-pixmap, image/x-portable-anymap

These are a family of file formats derived from Jef Poskanzer's Portable Bitmap Utilities suite. These file formats are Portable Bitmap (PBM), Portable Graymap (PGM), Portable Pixmap (PPM) and Portable Anymap (PNM). Because of their wide support and the free availability of software to handle these formats, these file formats are frequently used for uncompressed image interchange.

PBM files are monochrome only (the term "bitmap" being used in the sense of a map of bits, that is, each pixel is either 0 or 1). PGM files are grayscale only, while PPM files are full color pixel maps.

PNM does not refer to a distinct file format, but instead refers to any of the other three types (PBM, PGM, or PPM). Images written using the file format designation PNMF will be written as the most appropriate variant depending on the input data content format.

These formats do not include data compression, but have two encoding formats: ASCII or RAW.

PCXF

extension: .pcx

mime: image/pcx

PCX, or PCXF in Oracle interMedia notation, is an early and widely used image file format developed for ZSoft's PC Paintbrush, and later used in derivatives of that program. Despite its ancestry, it provides support for many pixel depths, from monochrome to 24-bit color. It supports a fast compression scheme designated PCXRLE by Oracle interMedia. Oracle interMedia reads but does not write PCX images.

PICT

extension: .pct

mime: image/pict

The Macintosh PICT format was developed by Apple Computer, Inc., as part of the QuickDraw toolkit built into the Macintosh ROM. It provides the ability to "record" and "playback" QuickDraw sequences, including both vector and raster graphics painting. Oracle interMedia supports only the raster elements of PICT files. Both Packbits and JPEG compressed PICT images are supported.

PNGF

extension: .png

mime: image/png

PNGF is the Oracle interMedia designation for the Portable Network Graphics (PNG) format (pronounced "ping"). PNG was developed by the PNG Development Group as a legally unencumbered and more capable replacement for some uses of the GIF and TIFF file formats. PNG includes support for deep images (up to 16 bits per sample and up to 4 samples per pixel), full alpha support, rich metadata storage including metadata compression, built-in error and gamma correction, a powerful and free compression algorithm called DEFLATE, and much more. The main feature found in GIF that is absent in PNG is the ability to store animations.

PNG support for a broad variety of pixel depths (1 bit to 16 bits per sample) makes it suitable for a very wide variety of applications, spanning the separate domains previously filled by GIF and JPEG, and being very similar to the uses of the powerful TIFF format. Because the DEFLATE compression scheme is lossless, PNG is a good choice for storing deep images that must be edited often.

All PNG images are compressed using the DEFLATE scheme.

RPIX

extension: .rpx

mime: image/x-ora-rpix

RPIX, or Raw Pixel, is a format developed by Oracle for storing simple raw pixel data without compression, and using a simple well-described header structure. It was designed to be used by applications whose native image format is not supported by interMedia but for which an external translation might be available. It flexibly supports N-banded image data (8 bits per sample) where N is less than 256 bands, and can handle data that is encoded in a variety of channel orders (such as RGB, BGR, BRG, and so forth), a variety of pixel orders (left-to-right and right-to-left), a variety of scanline orders (top-down or bottom-up) and a variety of band orders (band interleaved by pixel, by scanline, and by plane). The flexibility of the format includes a data offset capability, which can allow an RPIX header to be prepended to other image data, thus allowing the RPIX decoder to read an otherwise compliant image format. See Appendix E for more information.

In addition to its support for 8-bits-per-sample data, RPIX supports single-band monochrome images compressed using the FAX3 and FAX4 compression schemes.

When an RPIX image is decoded, only 1 or 3 bands are read. Which bands are selected can be determined by the image header or by the InputChannels operator. Similarly, interMedia writes only 1 or 3 band RPIX images.

RASF

extension: .ras

mime: image/x-ora-rasf

The Sun Raster image format, called RASF by interMedia, was developed by Sun Microsystems for its UNIX operating systems and has a wide distribution in the UNIX community. It supports a variety of pixel depths and includes support for a format-specific, run-length encoding compression scheme called SUNRLE by interMedia.

TGAF

extension: .tga

mime: image/x-ora-tgaf

The Truevision Graphics Adapter format (TGA, or TGAF to interMedia) was developed by Truevision, Inc., for their line of Targa and related graphics adapters. This format includes support for color images with 8, 16, 24, and 32 bits per pixel, and also includes support for a run-length encoding compression scheme called TARGARLE by interMedia.

TIFF

extension: .tif

mime: image/tiff

The Tag Image File Format (TIFF) was originally developed by the Aldus Corporation. The format has become something of a benchmark for image interchange and is extremely versatile, including support for a wide variety of compression and data formats, multiple image pages per file, and a wide variety of metadata. Because of its many options, TIFF is a good choice for many applications, including document storage, simple art, photographic and photo-realistic images, and others.

Oracle interMedia supports the "baseline TIFF" specification and also includes support for some TIFF "extensions," including tiled images and certain compression formats not included as part of the baseline TIFF specification. "Planar" TIFF images are not supported. It is important to note that the JPEG support in TIFF provided by interMedia is based on the revised JPEG in TIFF specification and not the original JPEG in TIFF specification. TIFF images in either big endian or little endian format can be read, but interMedia always writes big endian TIFFs.

Although the TIFF decoder in interMedia includes support for page selection using the "page" verb in the process( ) and processCopy( ) methods, the setProperties( ) method always returns the properties of the initial page in the file. It is important to note that this initial page is accessed by setting "page=0" in the process command string. Oracle interMedia currently does not support writing multiple page TIFF files.

WBMP

extension: .wbmp

mime: image/vnd.wap.wbmp

The Wireless Bitmap format (WBMP) was developed for the Wireless Application Protocol (WAP) as a means of transmitting bitmap (monochrome) images to WAP-compliant devices. An extremely minimalist format, it does not even include identifying markers or support for compression. It is most appropriate for very small images being transmitted over limited bandwidth networks.

The WBMP format is not related to the BMPF format.

B.2 Image Compression Formats

Image compression formats are listed alphabetically.

ASCII

Not an actual compression format by itself, ASCII is an encoding format used by PBM, PGM, and PPM images to represent images in plain ASCII text form. Each pixel value is represented by an individual integer in an ASCII-encoded PBM (or PGM or PPM) file.

BMPRLE

BMPRLE is the description that Oracle interMedia gives to images that are compressed with the BMP run-length encoding compression scheme. This compression format is available only for 4-bit and 8-bit LUT data, and only for images that are stored in INVERSE scanline order (the default order for BMP files). For very complex images, this compression can occasionally actually increase the file size.

DCMRLE

DCMRLE is the description used within interMedia for the run-length encoding scheme used in DICOM images. For very complex images, this compression can occasionally actually increase the file size.

DEFLATE

DEFLATE is the compression scheme employed by the PNG image format, and has also been adapted to work in the TIFF image format. DEFLATE is based on the LZ77 algorithm (which is used in various zip utilities) and is a very adaptable compression scheme that handles a wide variety of image data formats well. Besides being used to compress image data in PNG and TIFF files, DEFLATE is also used within PNG files to compress some metadata.

DEFLATE-ADAM7

DEFLATE-ADAM7 is the same compression format as DEFLATE, but refers to images whose scanlines are interlaced for progressive display as the image is decoded. The intention of this technique is to allow a user to observe the image being progressively decoded as it is downloaded through a low bandwidth link, and quit before completion of the download. While the low bandwidth requirement is not typically relevant anymore, many existing images employ this encoding. Unlike JPEG-PROGRESSIVE and GIFLZW-INTERLACED, DEFLATE-ADAM7 interlaces images both horizontally and vertically.

Oracle interMedia provides read support for this encoding, but does not provide write support.

FAX3

FAX3 is the interMedia designation for CCITT Group 3 2D compression, which was developed by the CCITT (International Telegraph and Telephone Consultative Committee) as a protocol for transmitting monochrome images over telephone lines by facsimile and similar machines. The more official designation for this compression scheme is CCITT T.4.

Because this compression format supports only monochrome data, it cannot be used for color or grayscale images. This compression scheme uses a fixed dictionary that was developed using handwritten and typewritten documents and simple line graphics that were meant to be representative of documents being transmitted by facsimile. For this reason, although the compression can be used on images that have been dithered to monochrome, it may not produce as high a compression ratio as more adaptive schemes such as LZW or DEFLATE in those cases. FAX3 is most appropriate for scanned documents.

FAX4

FAX4 is the interMedia designation for CCITT Group 4 2D compression, which was developed by the CCITT (International Telegraph and Telephone Consultative Committee) as a protocol for transmitting monochrome images over telephone lines by facsimile and similar machines. The more official designation for this compression scheme is CCITT T.6.

Because this compression format supports only monochrome data, it cannot be used for color or grayscale images. This compression scheme uses a fixed dictionary that was developed using handwritten and typewritten documents and simple line graphics that were meant to be representative of documents being transmitted by facsimile. For this reason, although the compression can be used on images that have been dithered to monochrome, it may not produce as high a compression ratio as more adaptive schemes such as LZW or DEFLATE in those cases. FAX4 is most appropriate for scanned documents.

GIFLZW

GIFLZW is the interMedia designation for the LZW compression system used within GIF format images, and is different from LZW compression as used by other file formats. GIFLZW is an adaptive compression scheme that provides good compression for a wide variety of image data, although it is least effective on very complex images, such as photographs.

GIFLZW-INTERLACED

GIFLZW-INTERLACED is the same compression format as GIFLZW, but refers to images whose scanlines are interlaced for progressive display as the image is decoded. The intention of this technique is to allow a user to observe the image being progressively decoded as it is downloaded through a low bandwidth link, and quit before completion of the download. While the low bandwidth requirement is not typically relevant anymore, many existing images employ this encoding.

Oracle interMedia provides read support for this encoding, but does not provide write support.

HUFFMAN3

HUFFMAN3 is the interMedia designation for the Modified Huffman compression scheme used by the TIFF image format. This compression format is based on the CCITT Group 3 1D compression format, but is not an official CCITT standard compression format.

Because this compression format supports only monochrome data, it cannot be used for color or grayscale images. This compression scheme uses a fixed dictionary that was developed using handwritten and typewritten documents and simple line graphics that were meant to be representative of documents being transmitted by facsimile. For this reason, although the compression can be used on images that have been dithered to monochrome, it may not produce as high a compression ratio as more adaptive schemes such as LZW or DEFLATE in those cases. HUFFMAN3 is most appropriate for scanned documents.

JPEG

The JPEG compression format was developed by the Joint Photographic Experts Group for storing photographic and photo-realistic images. The JPEG compression format is very complex, but most images belong to a class called "baseline JPEG," which is a much simpler subset. Oracle interMedia supports only baseline JPEG compression.

The JPEG compression scheme is a lossy compression format; that is, images compressed using JPEG can never be reconstructed exactly. JPEG works by eliminating spatial and chromatic details that the eye will probably not notice. While JPEG can compress most data quite well, the results may include serious cosmetic flaws for images that are not photographic, such as monochrome or simple art. Other compression schemes are more appropriate for those cases (FAX formats or PNG and GIF). Also, the lossy nature of this compression scheme makes JPEG inappropriate for images that must be edited, but it is a good choice for finished images that must be compressed as tightly as possible for storage or transmission.

JPEG-PROGRESSIVE

This compression format is a variation of the JPEG compression format in which image scanlines are interlaced, or stored in several passes, all of which must be decoded to compute the complete image. This variant is intended to be used in low bandwidth environments where users can watch the image take form as intermediate passes are decoded, and terminate the image display if desired. While the low bandwidth requirement is not typically relevant anymore, this variant sometimes results in a smaller encoded image and is still popular. Oracle interMedia provides read, but not write, support for this encoding.

LZW

LZW is the interMedia designation for the LZW compression system used within TIFF format images, and is different from LZW compression as used by other file formats. TIFF LZW is an adaptive compression scheme that provides good compression for a wide variety of image data, although it is least effective on very complex images. TIFF LZW works best when applied to monochrome or 8-bit grayscale or LUT data; the TIFF method of applying LZW compression to other data formats results in much lower compression efficiency.

LZWHDIFF

LZWHDIFF is the description that interMedia gives to images employing the TIFF LZW compression system and also utilizing the TIFF horizontal differencing predictor. This scheme is a technique that can improve the compression ratios for 24-bit color and 8-bit grayscale images in some situations, without loss of data. It generally does not improve compression ratios for other image types.

NONE

This is the description that interMedia gives to image data that is not compressed.

PACKBITS

The Packbits compression scheme was developed by Apple Computer, Inc., as a simple byte-oriented, run-length encoding scheme for general use. This scheme is used by the PICT image format and has been adapted to work in TIFF images as well. Like other run-length encoding schemes, this compression can actually increase the data size for very complex images.

PCXRLE

PCXRLE is the description given by interMedia to images that are compressed using the PCX run-length encoding scheme. For very complex images, this compression can occasionally actually increase the file size.

RAW

Not an actual compression format by itself, RAW is encoding used by PBM, PGM, and PPM images to represent images in binary form (versus the plain text form employed by the ASCII encoding). The PBM documentation refers to this format as RAWBITS.

SUNRLE

SUNRLE is the description used within interMedia for the run-length encoding scheme used in Sun Raster images. For very complex images, this compression can occasionally actually increase the file size.

TARGARLE

TARGARLE is the description given by interMedia to images compressed using the run-length encoding scheme supported by the TGAF file format. For very complex images, this compression can occasionally actually increase the file size.

B.3 Summary of Image File Formats and Image Compression Formats

Table B-1 summarizes the input and output support provided for process( ) and setProperties( ) methods for image file formats relative to content format characteristics, such as content format, interpretation, and color space. Table B-2 summarizes input and output support provided for process( ) and setProperties( ) methods for image file formats relative to compression format. Table B-3 summarizes input and output support provided for process( ) and setProperties( ) methods for other format-specific characteristics, such as pixel layout, channel order, pixel order, and scanline order.

The following abbreviations are used in Table B-1, Table B-2, and Table B-3:

• I = Input support is provided for process( ), processCopy( ), and setProperties( ) methods

• O = Output support is provided for process( ) and processCopy( ) methods

• - = Neither input nor output support is provided

^Footnote 1 RGB + Alpha, RGB + transparency, GRAY + Alpha, GRAY + transparency.
^Footnote 2 Supports 8-bit to 16-bit grayscale MONOCHROME2 image types.
^Footnote 3 Animated GIFFs may not be encoded.
^Footnote 4 Supports EXIF images.
^Footnote 5 Vector and object graphics are not supported.
^Footnote 6 PNMF format is supported as PBMF, PGMF, or PPMF; output will be PBMF, PGMF, or PPMF as appropriate.
^Footnote 7 Can decode 1 or 3 bands from an n-band image; only 1 or 3 bands may be encoded.
^Footnote 8 TIFF image file format also supports the following content formats as input or input/output (I/O) as specified: Tiled data - input, Photometric interpretation - input/output (I/O), MSB - input/output (I/O), and LSB - input; Planar (BSQ) is not supported; both MSB and LSB ordered files may be decoded; decoded output is MSB.
^Footnote 1 Supports 8-bit grayscale and 24-bit RGB data only.
^Footnote 2 Supports 8-bit and 24-bit data only.
^Footnote 3 Supports MONOCHROME2 data only.
^Footnote 4 Compression is supported only for scanlineOrder=INVERSE (inverse DIB), which is the default.
^Footnote 5 Supports EXIF images.
^Footnote 1 Animated GIFFs may not be encoded.
^Footnote 2 Supports EXIF images.
^Footnote 3 Vector and object graphics are not supported.
^Footnote 4 PNMF format is supported as PBMF, PGMF, or PPMF; output will be PBMF, PGMF, or PPMF as appropriate.
^Footnote 5 Can decode 1 or 3 bands from an n-band image; only 1 or 3 bands may be encoded.
^Footnote 6 TIFF image file format also supports the following content formats as input or input/output (I/O) as specified: Tiled data - input, Photometric interpretation - input/output (I/O), MSB - input/output (I/O), and LSB - input; Planar (BSQ) is not supported; both MSB and LSB ordered files may be decoded; decoded output is MSB.