3DSoftware.com: File Formats

3DSoftware.com > Programming > File Formats > BIP > Page 2

BIP File Format Page 2

Overview

The BIP (Bit Planes Grid) format stores one or more bit planes in a file.

A bit plane is also called a channel or monochrome image. Color images can be multiple channels but are not supported in this file format (to support color images use the FIN file format). The BIP file format supports monochrome images, and each monochrome image equals one channel.

If the BIP file contains more than one image, each image must be the same size (the same number of bits wide and high).

“we may consider an image as consisting of a collection of channels… it often helps to separate the channels for convenience in storage.”

–	Foley, van Dam, et.al. Computer Graphics 2nd ed.w/C, p. 844

Bitmap image pixels, in uncompressed scan lines (rows), are 1 bit each, 8 bits per byte. Black is color 0, and white is color 1, unless all applications that use a file agree to the reverse color assignment.

Bit order within each byte can be either beginning with the most significant bit (high bit first) or beginning with the least significant bit (low bit first). Historically, graphic images used high bit first, and data images used low bit first. New applications can use whichever bit order within a byte works best for their particular work.

Grid

Each bit in a bit plane is a grid node. The grid can be broken up into (stored as) tiles, or blocks and/or diagonal bands. This breaking up of the grid is the same for all bit planes in a file (e.g., if one bit plane is tiled, the other bit planes are tiled the same way).

Tiles are rectangular. Blocks can be rectangular or triangular. Bands are stepped: each row after the first row of a band starts one column to the right of the previous row of that band.

If tiles are used, then blocks and bands cannot be used. If blocks and/or bands are used, then tiles cannot be used. If tiles, blocks and bands are not used, then the entire grid is stored intact (not partitioned or broken up).

When using tiles, if a tile is not stored, each grid node (pixel) that is supposed to be in that tile is assumed to be the Default Color. That helps reduce file size for sparse matrices. When writing a tile to disk, if all the pixels in the tile are the Default Color, then do not save the tile, and set its tile address to zero.

Tiles cannot overlap. If tiling is used, tiles are adjacent and provide full grid coverage (every possible grid node will be in a tile) without duplication (each node will be in only one tile). If blocks and/or bands are used instead of tiles, duplication of nodes is allowed, and full coverage of nodes is not required: grid nodes that are not in a block or band are not stored and are considered to be the Default Color.

Tiles and blocks do not extend past the edges of the grid. Bands can extend past the left and right edges of the grid, in which case the nonexistent nodes are not saved and are considered to be the Default Color.

If tiles are used, all tiles are the same number of nodes wide and high, except the right tiles are truncated (made less wide) if the grid width is not an integral multiple of the tile width, and the bottom tiles are truncated (have less rows) if the grid height is not an integral multiple of the tile height.

Raster scan is left to right, top to bottom

“the raster…is a set of horizontal raster lines, each a row of individual pixels; the raster is thus stored as a matrix”

–	Foley, van Dam, et.al., Computer Graphics 2nd ed. w/C, p.11

Tiles are stored sequentially in raster order: the tiles are stored as rows of tiles, beginning with the top row of tiles; each row of tiles begins with its left-most tile.

Each tile consists of scan lines (rows of data) in raster order, beginning with the tile's top row. Pixel (data) bytes proceed from left to right within each scan line: the left-most 8 bits of a row are the first byte in a scan line, the next 8 bits are the next byte, etc.

Uncompressed scan lines begin on byte boundaries. The next scan line always begins with a new byte (will not start within a byte of the previous row).

If the tile width (number of pixels wide) is not a multiple of 8, then the last byte in each uncompressed scan line has extra unused bits which should be all zeroes or all ones.

Scan lines are stored sequentially, one after the other, without interleaving. There are no pad bytes between scan lines: the first byte of a scan line immediately follows the last byte of the previous scan line.

If there is more than one image (more than one bit plane), each image is called a channel, and each tile stores the grid nodes (pixel data) from that tile in the first channel, followed by the pixel data from that tile in the second channel, etc. There is no interleaving and no extra (pad) bytes between scan lines or between channels.

Compression

Compression is ON or OFF for the entire image.

If compression is ON, some tiles may be compressed and other tiles may be uncompressed. For example, you can decide to only compress tiles that reduce the file size. It is possible that no tiles are compressed even if compression is ON for the file.

Compression can be CCITT, RLE, ZLIB, or RLE and ZLIB.

If RLE and ZLIB are used, to compress data, first RLE is performed then ZLIB compression. Later, to uncompress, first ZLIB decoding is performed then RLE decoding.

MSBFIRST Byte Order

Any variable that is multi-byte (such as a 4-byte integer) is stored with most significant byte first. This byte ordering is called “MSBFIRST” or “Network Byte Order.” All multi-byte variables in a BIP file use MSBFIRST byte ordering. The MSBFIRST page has C/C++ source code to read and write a multi-byte number.

Byte streams can be written directly to (and read directly from) disk file as you normally do (without special functions), because byte stream elements are not multi-byte. Each element (variable) in a byte array is a single byte.

— Page 2 —

« Page 1

Contents

Page 3 »

Tuesday, 06-Jan-2009 03:49:25 GMT