![[Graphic: Figure INGR-1]](./ingr01.gif)
Also Known As: INGR
| Type | Bitmap |
| Colors | 1- to 128-bit |
| Compression | RLE, CCITT Group 4, JPEG, Uncompressed |
| Maximum Image Size | 4Gbx4Gb pixels |
| Multiple Images Per File | Yes |
| Numerical Format | Little-endian |
| Originator | Intergraph |
| Platform | All |
| Supporting Applications | Intergraph |
| See Also | TIFF |
Usage
The INGR format is typically used to store raster data for use
by Intergraph software. This format also contains special features
that add to the performance of Intergraph software.
Comments
The INGR file format was proprietary for a long time and
was not well known outside of INGR customer sites. It has now been
released to the public, and its use is encouraged by Intergraph
especially for use with Intergraph software.
The Intergraph Raster File Format (INGR) is the native file format used by Intergraph software applications to store raster data. Intergraph develops, manufactures, sells, and supports computer systems for interactive computer graphics and technical desktop applications. Such applications, known collectively as Interactive Graphics Design Software (IGDS), include manufacturing, publishing, CAD/CAM, GIS (Geographical Information Systems), and remote sensing.
Contents:
File Organization
File Details
For Further Information
In 1980, Intergraph was a Value Added Reseller of DEC equipment, adding graphics processing hardware and CAD/CAM software to its systems. As the more powerful VAX series of computer became more popular, Intergraph began to specialize in mapping and scanning applications. The plotting of wireframe and shaded models required raster data to be sent to various types of printers and plotters. The need to consolidate many different types of raster data into a single format arose. In 1984, Intergraph started a project to consolidate and describe all of the different raster file formats they used into a single format.
By 1986 the INGR format had emerged. It was capable of storing a variety of raster data and its design allowed for future expansion and features. Originating on the DEC VAX system, INGR included native VAXen architecture features, such as a 512-byte data block size and usage of the little-endian byte order.
It was also about this time that Intergraph began to transition from VAX systems to a RISC-based workstation built around on the Fairchild Clipper chip (not to be confused with the U.S. government's failed encryption chip of the same name). By 1985, Intergraph was shipping workstations running CLIX, a variant of SysV UNIX running on the Clipper chip. Soon after this, National Semiconductor bought Fairchild and was going to stop production of the Clipper. Intergraph bought the fabrication plant and the rights to Clipper and continued producing and improving the chip. Intergraph continued to grow, moving into new software markets and continuing to improve the Clipper, reaching a billion dollars in worldwide sales in 1991.
It was also in the early 1990's that Intergraph decided that, with the more powerful CPU architectures appearing, the distinctions between PCs and workstations was becoming less clear. It seemed that the Windows/Intel combination was going to win out in the high-end PC and low-end workstation markets. Intergraph sold the Clipper fabrication plant to Sun Microsystems and began producing high performance Intel-based PCs running Windows NT. It is guessed that at one time Intergraph had more people writing code for WinNT than anyone in the world--including Microsoft.
Intergraph software today has been ported to DOS, Unix, Windows NT, and the Apple Macintosh. Intergraph's current directions fall along two main lines, corresponding to its two main business units, ICS (Intergraph Computer Systems) and ISS (Intergraph Software Solutions). The Intel-based Personal Workstations and Interserve line of PCs built by ICS are some of the most technically advanced and powerful computers in the market. The new object oriented drafting and modeling products, Imagineer and Solid Edge, produced by ISS provide a low-cost, yet powerful and extensible solution for many workstation users.
The INGR format was officially released to the public in 1991 and supports a bewildering variety of raster data formats and compression methods, including tiling and multiple overviews at various resolutions. Many of the earlier data formats, such as integer and floating point array bitmaps, are considered obsolete, and it is recommended that no new files be created using these data formats. The newest data formats added to INGR include CMYK line work and continuous tone (added in 1989) and JPEG (added in 1991).
An interesting parallel format to INGR is TIFF. The 1980's was also the time when TIFF was being developed by a consortium of scanner, printer, and software companies with needs and interest in the storage of raster data. The first major public release of TIFF Revision 5 on August 8, 1988, saw the adoption of TIFF by many companies as a primary means of storing raster data. Intergraph was among those companies and today recommends using TIFF for storing data that must be used by a wide variety of software applications. Intergraph has also been one of the supporters and early adopters of GeoTIFF, a set of extensions to TIFF format for mapping and GIS applications.
TIFF files only have the extension ".tif", or the file type "tiff". There is no standard way to discern by the filename the type of bitmap data a TIFF file contains (often a source of frustration to people working with TIFF files). INGR files have the opposite problem. It is common for an INGR file to have a different extension for each type of data the file can contain. This is a problem because the extensions have never been standardized. There may be several different extensions for the same type of INGR file, or a single extension used by several different types of INGR files. This has occurred largely because many Intergraph customers use their own file naming conventions.
The following is a partial listing of INGR file extensions:
.cot |
8-bit grayscale or color table data |
.ctc |
8-bit grayscale using PackBits-type compression (uncommon) |
.rgb |
24-bit color and grayscale (uncompressed and PackBits-type compression) |
.ctb |
8-bit color table data (uncompressed or run-length encoded) |
.grd |
8, 16 and 32 bit elevation data |
.crl |
8 or 16 bit, run-length compressed grayscale or color table data |
.tpe |
8 or 16 bit, run-length compressed grayscale or color table data |
.lsr |
8 or 16 bit, run-length compressed grayscale or color table data |
.rle |
1-bit run-length compressed data (16-bit runs) |
.cit |
CCITT G3 or G4 1-bit data |
.g3 |
CCITT G3 1-bit data |
.g4 |
CCITT G4 1-bit data |
.tg4 |
CCITT G4 1-bit data (tiled) |
.cmp |
JPEG grayscale, RGB, or CMYK |
.jpg | JPEG grayscale, RGB, or CMYK |
Each INGR file contains a single header composed of two more subheaders called Header Blocks. Each Header Block is exactly 512 bytes in length and an INGR file may contain as many Header Blocks as necessary to provide a proper interpretation of the raster data.
Three major versions of the INGR file format exist. Versions 1 and 2 always have only two header blocks, and therefore always a contain a header 1024 bytes in length. The version 3 file header contains two or more header blocks, and therefore may vary in length starting at 1024 bytes and increasing in increments of 512 bytes. See Figure INGR-1.
The first Header Block and the first half of the second Header Block contains INGR header data. The last half of the second Header Block is reserved for the color map or application-specific data. Version 3 of INGR added the capability of appending extra 512 byte header blocks for storing additional application-specific data. This additional data is stored as Application Packets (described later), and are considered to be part of the header.
Multi-image INGR files are created by simply concatenating two or more INGR files together into a single file and storing the starting offset of each header. Multiple-images are linked together by a chain of offset values located in Header Block 2. See Figure INGR-2.
![[Graphic: Figure INGR-2]](./ingr02.gif)
INGR files may contain one or more lower-resolution version of a stored image. These "overview" images are used to give a user a quick display the contents of an INGR image file. Overview data is always stored following the raster data it is associated with. See Figure INGR-3.
![[Graphic: Figure INGR-3]](./ingr03.gif)
Version 1 INGR files, and v2 files prior to 1987, use the DEC VAX floating point format and DEC VAX string format (leading character count followed by string data) to store data. Starting in 1987, v2 was changed to use the IEEE floating point formats and NULL-terminated ASCII strings. Therefore, many v2 files use the older VAX data formats, and many other v2 files use the newer data formats. All v3 files use IEEE floating point and NULL-terminated strings. Unused header fields are always set to 0 an several fields are required to be initialized with valid data.
Header Block 1 always occurs first in every INGR file, is always 512 bytes in length, and has the following format:
typedef struct _HeaderBlockOne
{
WORD HeaderTypeCode; /* File ID value (always 0908h) */
WORD WordsToFollow; /* Number of WORDs following this field */
WORD DataTypeCode; /* Format of the raster data */
WORD ApplicationType; /* Creator application identifier */
DOUBLE XViewOrigin; /* Raster grid data X origin */
DOUBLE YViewOrigin; /* Raster grid data Y origin */
DOUBLE ZViewOrigin; /* Raster grid data Z origin */
DOUBLE XViewExtent; /* Raster grid data X offset */
DOUBLE YViewExtent; /* Raster grid data Y offset */
DOUBLE ZViewExtent; /* Raster grid data Z offset */
DOUBLE TransformMatrix[16]; /* Raster data and IGDS coordinates map */
DWORD PixelsPerLine; /* Width of a scan line in pixels */
DWORD NumberOfLines; /* Height of the raster data in scanlines */
SHORT DeviceResolution; /* Resolution of scanning device */
BYTE ScanlineOrient; /* Origin and scanning direction */
BYTE ScannableFlag; /* Scanline indexing method used */
DOUBLE RotationAngle; /* Rotation angle of raster data */
DOUBLE SkewAngle; /* Skew angle of raster data */
WORD DataTypeModifier; /* Additional raster data format info */
BYTE DesignFile[66]; /* Name of the design file */
BYTE DatabaseFile[66]; /* Name of the database file */
BYTE ParentGridFile[66]; /* Name of parent grid file */
BYTE FileDescription[80]; /* Text description of file and contents */
union _MinValue
{
BYTE MinValueI1; /* Minimum raster data BYTE value */
WORD MinValueI2; /* Minimum raster data WORD value */
DWORD MinValueI4; /* Minimum raster data DWORD value */
FLOAT MinValueR4; /* Minimum raster data FLOAT value */
DOUBLE MinValueR8; /* Minimum raster data DOUBLE value */
} MinValue;
union _MaxValue
{
BYTE MaxValueI1; /* Maximum raster data BYTE value */
WORD MaxValueI2; /* Maximum raster data WORD value */
DWORD MaxValueI4; /* Maximum raster data DWORD value */
FLOAT MaxValueR4; /* Maximum raster data FLOAT value */
DOUBLE MaxValueR8; /* Maximum raster data DOUBLE value */
} MaxValue;
BYTE Reserved[3]; /* Unused (always 0) */
BYTE GridFileVersion; /* Grid File Version */
} HEADERBLOCKONE;
HeaderTypeCode is the identification value for Intergraph raster files. The value for this field is always 0908h, indicating IGDS element type 9 (bits 8:15), version 8 (bits 0:8), and storing 2D data (bits 6:7). This is a required field.
WordsToFollow indicates the number of 16-bit WORDs remaining in the header that follow this field. Typically, there are 254 WORDs following this field in Block 1. Each header block thereafter (Block 2, Block 3, etc.) will contain 256 WORDs. To find the total number blocks in the header, use the formula NumberOfBlocks = (WordsToFollow + 2) / 256. This is a required field.
DataTypeCode indicates the format of the raster data and method of data compression used and is a required field. This field also indicates the depth of the pixel data. Note that a value of 0 to indicate no raster data exists in the file is non-standard and many INGR file readers may not accept this value as valid. The following values may be found in this field:
| 0 | No data | |
| 1 | Packed binary | 1 bit per pixel (Obsolete) |
| 2 | BYTE array | 8 bits per pixel |
| 3 | WORD array | 16 bits per pixel |
| 4 | DWORD array | 32 bits per pixel |
| 5 | FLOAT array | Obsolete |
| 6 | DOUBLE array | Obsolete |
| 7 | Complex array | 64 bits per pixel (Obsolete) |
| 8 | DOUBLE Complex | Obsolete |
| 9 | Run-Length Encoded | 1-bit |
| 10 | Run-Length Encoded | Grayscale or color |
| 11 | Figure Of Merit | Reserved |
| 12 | DTM Flags | Reserved |
| 13 | RLE Variable Values | Simple and with Z (Obsolete) |
| 14 | RLE Binary Values | with Edge Type (Obsolete) |
| 15 | RLE Variable Values | with Edge Type (Obsolete) |
| 16 | RLE Variable Values | with Edge Type and Z (Obsolete) |
| 17 | RLE Variable Values | Color Table and Shade (Obsolete) |
| 18 | RLE Variable Values | with Normals |
| 19 | Quadtree-Encoded | |
| 23 | CCITT Group 3 | 1-bit |
| 24 | CCITT Group 4 | 1-bit |
| 25 | Run-Length Encoded | RGB |
| 26 | Variable Run-Length | |
| 27 | Adaptive RLE | RGB |
| 28 | Uncompressed truecolor | 24 bits per pixel |
| 29 | Adaptive RLE | Grayscale |
| 30 | JPEG | Grayscale |
| 31 | JPEG | RGB |
| 32 | JPEG | CMYK |
| 65 | Tiled | |
| 66 | Not used | Reserved |
| 67 | Continuous Tone | CMKY |
| 68 | Line Art | CMYK/RGB |
| 69 | Continuous Tone | CMKY (Uncompressed) |
ApplicationType is a value identifying the type of application that created the image file and is a required field. The following values are defined for use in this field:
| 0 | Generic raster image |
| 1 | Digital Terrain Modeling (DTM) |
| 2 | Grid Data Utilities |
| 3 | Drawing, Scanning |
| 4 | Image Processing |
| 5 | Hidden Surfaces |
| 6 | Imagitex Scanner Product |
| 7 | Screen Copy, Plotting |
| 8 | I/IMAGE and MicroStation Imager |
| 9 | ModelView |
If the ApplicationType value is not recognized, only the data in Block 1 and the first 128 bytes of data in Block 2 should be used. The remaining data in the header should be ignored. In older versions of the INGR format, the last 128 bytes of Block 2, and any header blocks that followed, were used for storing application-specific data. The current specification only allows the storage of application-specific data within Application Packets.
XViewOrigin, YViewOrigin, and ZViewOrigin are used by Digital Terrain Mapping applications to define the relationship of the grid file (pointed to by the ParentGridFile field) to the raster data. The XViewOrigin and YViewOrigin values indicate the upper-left corner of the grid file in Units Of Resolution (UOR) space. These fields are only used in early versions of INGR. Version 3 files only use the TransformMatrix field array, and set these three values to 0.
XViewExtent, YViewExtent, and ZViewExtent are used by Digital Terrain Mapping applications to store the column and row spacings of the grid file data and are stored in Units Of Resolution (UOR). These fields are only used in earlier version of INGR, and their use has been replaced in v3 by the TransformMatrix field array.
TransformMatrix contains a 4x4 array of data used to define the orientation of the raster data to the world or local coordinate system. The array data specifically defines the origin, scaling, and rotation matrices of the raster data.
PixelsPerLine is the number of pixels in a scan line of bitmapped data. All scan lines in a bitmap contain the same number of pixels.
NumberOfLines is the number of scan lines in a bitmap.
DeviceResolution specified the resolution at which the image was scanned. A positive value indicates the number of micros between scan lines; a negative value indicates the number of pixels (or lines) per inch. This field will contains a value of 0 if the resolution is unknown or meaningless.
ScanlineOrient indicates the origin of the image and the orientation of the scan lines. The origin may be in any one of the four corners of the scanner or display. The line orientation may be horizontal or vertical, depending upon how the object was placed on the scanner. Bit 0 indicates the left or right position of the origin, bit 1 the upper or lower position, and bit 2 the line orientation:
| Origin | Line Orientation | Value |
|---|---|---|
| Upper Left | Horizontal | 04h |
| Upper Left | Vertical | 00h |
| Upper Right | Horizontal | 05h |
| Upper Right | Vertical | 01h |
| Lower Left | Horizontal | 06h |
| Lower Left | Vertical | 02h |
| Lower Right | Horizontal | 07h |
| Lower Right | Vertical | 03h |
ScannableFlag indicates the method used to index the scan lines in the bitmap data. Valid values are 0 (no scan line headers are present), and 1 (scan line leaders are present). Refer to the section on Image Data for more information on scan line headers.
RotationAngle indicates the clockwise rotation of the raster image using the specified raster data coordinate system. Use of this field has been replaced by the TransformMatrix array field.
SkewAngle contains an array of values used to represent the angle of skew of a raster image. Use of this field has been replaced by the TransformMatrix array field.
DataTypeModifier possibly contains information additional to the DataTypeCode field. If DataTypeCode is set to a value of 26 (Variable Run-Length) an additional definition value may appear in the DataTypeModifier field. This field is only used in earlier version of INGR and in Version 3 is considered obsolete.
DesignFile is a 66-byte field containing the name and path of a design, grid, or coordinate system file associated with this image. The name is a NULL-terminated string and is also padded using NULLs.
DatabaseFile is a 66-byte field containing the name and path of the database file associated with this image. The name is a NULL-terminated string and is also padded using NULLs. This field is is only used in older version of INGR and under Version 3 is considered obsolete.
ParentGridFile is a 66-byte field containing the name and path of the raster data file this image was derived from. The name is a NULL-terminated string and is also padded using NULLs. This field is is only used in older version of INGR and under Version 3 is considered obsolete.
FileDescription is an 80-byte field containing a (hopefully) useful human-readable description of the file and its contents.
MinValue is the minimum raster data (pixel) value in the bitmap. This field is 8 bytes in length its interpretation is application dependent. It is realized here as an 8-byte union with five field representing the file possible pixel sizes.
MaxValue is the maximum raster data (pixel) value in the bitmap. This field is 8 bytes in length its interpretation is application dependent. It is realized here as an 8-byte union with five field representing the file possible pixel sizes.
Reserved is a three-byte field used for alignment padding. This field is always set to 0.
GridFileVersion identifies the version number of the INGR raster file. This is a required field.
Header Block 2 contains the remaining fields in the header and an application-specific data area. Version 3 file writers should not store data in the ApplicationData field, but instead use one or more Application Packets instead. Header Block 2 is 512 bytes in length and has the following format:
typedef struct _HeaderBlockTwo
{
BYTE Gain; /* A-to-D converter gain */
BYTE OffsetThreshold; /* A-to-D parameters */
BYTE ViewScreen1; /* Frame buffer 1 */
BYTE ViewScreen2; /* Frame buffer 2 */
BYTE ViewNumber; /* Number of window to display image */
BYTE Reserved1; /* Unused (always 0) */
WORD Reserved2; /* Unused (always 0) */
DOUBLE AspectRatio; /* Pixel aspect ratio */
DWORD NextImageOffset; /* Offset to next image in the file */
WORD ColorTableType; /* Type of color table */
WORD Reserved3; /* Unused (always 0) */
DWORD ColorTableEntries; /* Number of color table entries */
DWORD StartOfAppPacket; /* Offset to start of application packet */
DWORD LenOfDataPackets; /* Total length of all app packets in WORDs */
WORD Reserved[110]; /* Unused (always 0) */
WORD ApplicationData[128]; /* Application-dependent data */
} HEADERBLOCKTWO;
Gain specifies the gain of the analog-to-digital converter used during scanning.
OffsetThreshold defines the threshold parameters of the analog-to-digital conversion for the scanning device.
ViewScreen1 and ViewScreen2 indicates which frame buffer on the CLIX platform to use for dipalying the image. A button on the display allows the user to flip from Screen 1 to Screen 2 and back.
ViewNumber is the number of the window to display the drawing. Up to eight different views of a vector drawing can be displayed, each in a different window.
Reserved1 and Reserved2 are unused field and are always set to 0.
AspectRatio indicates the height and width of the pixels in the raster data. This value is determined by dividing the pixel width by the pixel height.
NextImageOffset contains an offset value to the next image in the file. If this value is 0, then this is the last image. The offset value is always the number of bytes from the beginning of the file.
ColorTableType specifies the type of color table used by the image, if any. Valid values are 0 (No color table), 1 (IGDS Color Table), and 2 (Standard Color Table). Refer to the section Color Table for more information on INGR color tables.
Reserved3 is an unused field and is always set to 0.
ColorTableEntries indicates the number of entries in a Standard color table. IGDS color tables always have a fixed number of 256 entries.
StartOfAppPacket contains an offset value to the first Application packet. The offset value is always the number of bytes from the beginning of the file. Refer to the section Application Packets for more information on application packets.
LenOfDataPackets specifies the total length of all application packets in WORDs.
Reserved is a 110-byte field reserved for future information. This field is always set to 0.
ApplicationData is a 128-byte field used to store application-specific data for the raster data (if any). If the ColorTableType field is set to 1, then this field will contain the color table. If unused, this field is set to 0. Note that the use of this field in Version 3 INGR files is discouraged, and it is strongly suggested that application-specific data instead be stored in Application Packets.
If an INGR image contains a color table it will be located in the last 128 bytes of Header Block 2, and possibly in Header Block 3 as well. The presence of a color table is indicated by the ColorTableType field value in Header Block 2. One of two color table formats may be used by an INGR raster image: the IGDS Color Table or the Standard Color Table.
An IGDS Color Table is a typical 256-entry, 768-byte, RGB color table with the following format:
typedef struct _IgdsColorTableEntry
{
BYTE Red; /* Red pixel component */
BYTE Green; /* Green pixel component */
BYTE Blue; /* Blue pixel component */
} IGDSCOLORTABLEENTRY;
IGDSCOLORTABLEENTRY IgdsColorTable[256];
The background color of the image is always assumed to be in the first (0th) element of the color table. The cursor color is stored in the last (255th) element. The first 128 bytes of the IGES Color Table will be located in Header Block 2 and the remaining 512 bytes in Header Block 3.
The Standard (or Environ-V) Color Table is a bit more flexible--and therefore more complex--in its design. This color table may have any number of entries in the range of 1 to 65535. The actual number of entries is declared in the ColorTableEntries field of Header Block 2. The entries may be stored in any order within the table, each having its own slot index. Each entry in the table is 8 bytes in length and contains four fields:
typedef struct _StandardColorTableEntry
{
WORD SlotNumber; /* Index position of the entry */
WORD Red; /* Red pixel component */
WORD Green; /* Green pixel component */
WORD Blue; /* Blue pixel component */
} STANDARDCOLORTABLEENTRY;
STANDARDACOLORTABLEENTRY StandardColorTable[ColorTableEntries];
An entry contains the typical Red, Green, and Blue components values, but as 16-bit quantities. If 8-bit values are stored in this field, then they will be stored in the most-significant byte of the WORD. Each entry also contains a SlotNumber field indicating its index position within the color map. Using the SlotNumber fields the entries are not position sensitive and may be written to the color map in any order. Standard color tables with up to 32 entries will be contained entirely in Header Block 2. Larger color tables will spill over into Header Block 3.
Application Packets are used to include additional information in an INGR file that is necessary for the interpretation of the raster data (such as multiple color maps, histograms, or a decryption key), or for the identification of the INGR file and its data.
Application Packets can also be used to build features that are not present in the INGR format. For example, multiple images stored within a single INGR file are linked together by offset values stored in Header Block 2 of each image. An application may find it more efficient to build an image offset table to store all the offset values in a single array. Scan line offset tables may also be built and used in place of scan line headers. Nested INGR-format files may also be stored using application packets.
All application packets must begin and end on a quadword (64-bit) boundary. The header of an application packet is 8 bytes in length and has the following format:
typedef struct _ApplicationPacket
{
WORD PacketType; /* Application packet data type */
WORD SubType; /* Application packet data subtype */
DWORD WordsToFollow; /* Number of WORDs following this field */
} APPLICATIONPACKET;
PacketType indicates the format of the application specific data in the packet. A packet containing an unrecognized values should be ignored. Valid values are:
| 1 | IGE (Intergraph Graphics Environment) |
| 2 | Image Processing Applications |
| 3 | DMANDS |
| 4 | GRASS |
| 5 | MapPublishing Applications |
| 6 | Mapping Applications |
| 7 | DTM (Digital Terrain Modeling) Applications |
| 8 | Scanning |
SubType is an additional value used to specify the format of the packet data. This value depends on the PacketType value.
WordsToFollow is the number of WORDs that follow this field. This field allows the application packet to be skipped by readers that do not require or recognize the data.
The application packet data immediately follows this header. The data may be any length in size up to (2**31)-1 WORDs in length.
INGR specification describes how to read and write application packets and their general format, but does not list any packets in detail. Although the specification states that the Intergraph Raster Review Board Chairman is responsible for registering customer-specific application packets and assigning packet ID values, there is no document listing all registered packets and their formats.
The type of raster data stored in an INGR file is indicated by the value of the DataTypeCode field in Block 1 of the header. At least 33 different raster data storage formats are defined by version 3 of INGR. Several of these formats are a legacy from the earlier versions 1 and 2 formats, and are now considered obsolete (specifically, raster data types 1, 5, 6, 7, 8, 11, 12, 13, 14, 15, 16, 17, and 19).
INGR files are capable of storing bilevel, grayscale, or color data, with bit depths ranging from 1 to 128 bits in size. Therefore, a wide variety of compression methods are also supported, including CCITT Group 3 (type 23) and Group 4 (type 24), JPEG (types 30, 31, and 32), and three run-length encoding algorithms (types 9, 10, 25, 27, and 29).
The run-length encoding algorithm used by INGR is strongly recommended as the RLE to use for compressing 8-bit data (type 29), and data stored as 8-bit components (type 27). INGR Adaptive RLE is nearly identical to the Macintosh PackBits algorithm used by the TIFF and PICT file formats. However, like PackBits, this RLE packs runs of identical byte values rather than bit values.
INGR Adaptive RLE has two types of packets that may be written to the file. The first is a two-byte encoded run packet. The first byte (the run-count byte) indicates the number of bytes in the run, the second byte stores the value of each byte in the run. The actual run count value is stored in the range of 1 to 128, indicating that 1 to 128 run values follow the run count byte.
The other type of packet, the literal run packet, stores 1 to 128 bytes literally in the encoded data stream without compression. Literal run packets are used to store data with very few runs, as found in very complex or noisy images. The literal run packet's run count is in the range of -1 to -128, indicating that 1 to 128 run values (-(run count)) follow the run count byte.
INGR Adaptive RLE differs from PackBits in that the run count stored by PackBits has one subtracted from its value. Therefore, a run count of 120 read from a PackBits data stream must have 1 added to it to obtain the correct run count value of 121. This run count value would simply be stored as 121 in an INGR Adaptive RLE data stream. This difference leaves PackBits with -128 as an undefined run count value (called a no-op) and INGR with 0 as an undefined run count value.
The type 27 data format is used for storing and encoding 24-bit RGB data. The data for each scan line is first stored as an array of 8-bit red components, followed by an array of 8-bit green components, and finally by an array of the 8-bit blue components. In other words, type 27 scan lines are stored as color planes (RRRRRRGGGGGGBBBBBB) rather than as pixels (RGBRGBRGBRGBRGBRGB). The INGR Adaptive RLE algorithm is then used to compress each 8-bit color plan array.
Type 25 data uses a simpler, but less efficient, algorithm than type 27 for compressing 24-bit RGB data. Each run packet in type 25 data is 4 bytes in length and contains an 8-bit red, green, and blue value followed by the run count. The run count indicates the number of pixels of the RGB value are in the run and may be in the range of 1 to 255, with 0 being undefined.
Type 10 INGR files store 8-bit grayscale or color-mapped data using the same RLE as described for type 25 data, with the exception that the encoded packets are composed of two 8-bit values (the index value followed by the run count), rather than four.
Type 9 INGR files store run-length encoded bilevel data, where each pixel is 1-bit in depth. 16-bit WORD values are used to indicate the number of pixels in a run. Each scan line begins with a 0 (background color) run count and is followed by a 1 (foreground color) run count. (Because the color alternates, it is not necessary to store the color of the run with the run count). This 0/1 pattern repeats until all of the pixels in a scan line have been encoded or decoded. Each encoded scan line must begin and end with a 0 color value, so zero-length 0 color values are inserted where necessary.
Although type 9 runs may be as long as 65535 pixels, it is recommended that runs be limited to 32767 pixels for compatibility with existing applications. If a very long run is to be broken into two run counts, a zero-length count must be inserted between them to preserve the alternating color pattern used by the algorithm.
JPEG compression is used in Type 30 (8-bit grayscale), Type 31 (24-bit RGB), and Type 32 (24-bit CMYK) image files. The data is "raw" JPEG and not the JFIF format (JPEG support was added to INGR before JFIF 1.0 was introduced). Note that tiled JPEG data must have full tiles, padded with the last pixel value in each scan line, if necessary.
One thing that Intergraph is missing from the INGR format specification is the precise description of their JPEG raster data format. Intergraph says that their JPEG data is a collection of the output of their CCube JPEG chip stored in the file at the location indicated by the tile map. The qtables and/or qfactor is stored in the header in an application packet that is not described in the INGR specification.
The data stream from the CCube processor is just a dump of JPEG-compressed data and does not contains the necessary marker segments (SOI, EOI, DQT, DHT, etc.) for interpreting the data as a JPEG interchange format. Without the markers, the INGR JPEG-compatible compressed data cannot be read by the Independent JPEG Group's software, and can only be decoded using INGR JPEG hardware.
Some types of raster data may include scan lines headers. These headers are present at the start of each scanline and aid software in seeking to a specific scan line, or past a specific number of scanlines. The scan line header is 8 bytes in length and has the following format:
typedef struct _ScanLineHeader
{
WORD Identifier; /* Header identifier (always 5900h) */
WORD WordsToFollow; /* WORDs in raster line following the field */
WORD LineNumber; /* Index number of scan line */
WORD PixelOffset; /* Offset of pixel within the scan line */
} SCANLINEHEADER;
Identifier is used to identify the start of a scan line header. This value is typically 5900h, but bits 0:7 may differ in value.
WordsToFollow is the number of WORDs of header and scan line data that follow this field.
LineNumber is a sequential number that identifies a specific scan line. Line numbers always begins with 1 and increment to 65535, after which the value rolls over to 0 or 1 and continues incrementing. A file with more than 65535 lines will therefore have scan line headers with identical line numbers.
PixelOffset is the offset location of the scan line pixel data following the scan line header. This value will be 0 if the data immediately follows the header.
Several raster data formats (specifically 27, 30 31, 32 67, 68, and 69) should never include scan line headers, as their presence would be considered corruption of the compressed raster data. In fact, Intergraph considers the use of scanline headers to be somewhat antiquated and discourages their use.
The INGR format supports the concept of tiled raster data (type 65). Very large raster data is often tiled to allows areas of the image to be displayed using a smaller amount of memory. The tiles themselves are square sections of the images and are referenced by a tile directory. This allows any tile to be easily located and also allows tiles to be stored in any order in the INGR file.
Tiled data is indicated by a DataTypeCode of 65. The actual format of the tiles data (8-bit gray scale, color-mapped, 24-bit RGB, JPEG CMYK, etc.) will be indicated in the tile directory application packet, as described in the INGR file format specification.
Overviews are what you might more commonly call thumbnail or postage stamp images. They are small, icon-like images that are a smaller resolution version of the primary image(s) stored in the file. A single overview may be present per image, or several overviews may be present providing multi-resolution versions of the same image. Overviews may be tiled or untiled.
Overviews are typically used in INGR files that store very high-resolution (that is, big) images. Many photogrammetry applications use data scanned from 10x10 inch photographic plates at a resolution of over 3000 DPI uninterpolated. This produces a file approximately a gigabyte in size.
To display these large images quickly at whatever resolution the user needs, a series of overviews of the image are generated at reduced factors of 2x, 4x, 8x, etc. and stored in the file. The overview that is approximately screen size is the one that is displayed. Sometimes eight or more overviews will be associated with an single image. It is therefore more common to find an INGR file with multiple overviews than it would to find one with a single overview. You are also not likely to find overviews in multi-image files. If a file is big enough to need overviews, it is too big to have other images appended to it.
Because larger INGR raster files make extensive use of tiling and overviews to make display updates very fast, it is therefore recommended that any INGR file reader should always be able to interpret both tiled files and files with overviews correctly.
For information on the specific implementation of INGR tiles raster file data and overviews, refer to the Intergraph Raster File Format Reference Guide.
The official INGR specification may be ordered directly from Intergraph. It is a nicely bound, high-quality, document that reflects Intergraph's understanding of how important it is to properly document all file formats--something most other companies often fail to do.
The specification:
"Intergraph Raster File Format Reference Guide", Intergraph Corporation, DRA220700, March 1994, Version 3.2.0, 84 pages.
May be ordered from:
Scanning Systems Division
Intergraph Corporation
Huntsville, AL 35894-0001 USA
Voice: 205-730-5441
Voice: 800-345-4856
FAX: 205-730-9441
BBS: 205-730-8786
Email: info@intergraph.com
WWW: http://www.intergraph.com/
FTP: ftp://ftp.intergraph.com/
Or FTP a PostScript copy of this document from:
ftp://ftp.intergraph.com/pub/bbs/scan/note/rffrgps.zip
Sample images may be found in the following self-extracting archive file:
ftp://ftp.intergraph.com/pub/bbs/scan/note/bilevel.exe
Questions about INGR may be emailed to Ed Grissom (egrissom@ingr.com) at Intergraph. Ed wrote and currently maintains Intergraph's Raster I/O library used my many of their software applications.
Copyright © 1996 O'Reilly & Associates, Inc. All Rights Reserved.