Also Known As: BIF
| Type | Bitmap Header Interchange |
| Colors | None |
| Compression | None |
| Maximum Image Size | None |
| Multiple Images Per File | No |
| Numerical Format | ASCII |
| Originator | Handmade Software Inc. |
| Platform | MS-DOS, UNIX |
| Supporting Applications | Image Alchemy |
| Specification on CD | No |
| Code on CD | No |
| Images on CD | No |
| See Also | HSI Raw |
Usage
BIF is used to store header information for bitmap formats that
do not have headers.
Comments
Although BIF is primarily intended to import generic bitmap data
into the Image Alchemy program, it is a good method of storing most any
bitmap data in a generic format for interchange between dissimilar
software applications.
BIF is a member of a family of file formats created by Handmade Software and used by their Image Alchemy program for generic bitmap data interchange. Image Alchemy is an image processing and file format conversion program that imports and exports many of the formats described in this book, and is available for both MS-DOS and UNIX systems.
Contents:
File Organization and Details
For Further Information
Image Alchemy can separate a supported image file into its header, color palette, and bitmap data. This information is respectively stored using the BIF, PAL, and Raw file formats. These files may then be used to load the bitmap data into other software programs that do not use conventional file formats. Image Alchemy also reads BIF, PAL, and Raw files and can convert the information they contain to any supported output format.
The BIF format stores only graphics file header information, such as height, width, and pixel depth, in a human-readable ASCII text format. The PAL format (also known as HSI Palette) stores color palette data, also using a simple ASCII format. Raw files store bitmap data using an ASCII or binary format and never contain a header or color palette. It is important to realize that the Raw files created with BIF files are not the same as the HSI Raw file format.
So of what use are BIF, PAL, and Raw files? Let's say you have a graphics application that can only save data in a raw, headerless format, and you would like to convert this data to a more widely-used format, such as TGA, PICT, or PNG. You can use a text editor to create a BIF file that contains the basic metrics of the data (the stuff you would find in a file header), and use Image Alchemy to read your BIF and Raw files and convert them to the format you need.
While I was writing up this article on BIF, I received a graphics file via email from someone requesting that I help them convert the unknown file to a "usable" format. The file's header contained only two DWORDs storing the height and with of the image. Following the header was uncompressed bitmap data.
To convert this file (which I named sample.bw), I first used a text editor to create a BIF file defining a bitmap file called sample.bw that was 256x256 pixels in size (based on the data in the file's header). I guessed that the bitmap data was gray-scale and was one byte per pixel in depth. I also indicated that Image Alchemy should skip over reading the first eight bytes of the file (the header).
With one quick command line operation of Image Alchemy, my BIF file was used to convert the unknown sample.bw to a TIFF file. My guess about the bitmap storing gray-scale data was correct, and the resulting TIFF file displayed correctly. I smugly emailed the converted image back to the original owner and have not heard from him since. You're welcome.
For another example, let's say that you need to write a software program that reads and writes bitmap data using several different formats, such as TIFF Type 4, TGA Truecolor RLE, GIF89A, PCX 24-bit, and both Windows and OS/2 BMP. To do this, you will spend a lot of time writing and testing your own code, or integrating a third-party file format library into your program. However, it would be much easier to use the BIF and Raw formats--and the Image Alchemy program--to add this functionality to your program, and do so much more quickly.
Instead of writing multiple formats, have your program only read and write BIF, PAL, and Raw files. If you need to read another format, such as TIFF, have your program call the Image Alchemy executable and convert the TIFF file to its BIF, PAL, and Raw equivalents. Your program will then read these files to import the bitmap data.
Exporting files is just the opposite procedure. Your program will write out BIF, PAL, and Raw files and call Image Alchemy to convert them to the desired output format. If Image Alchemy doesn't read or write a file format you need, then call or email the happy programmers at Handmade Software and request that their next version of Image Alchemy support your every image conversion need. Tell them the file format guys from O'Reilly sent you.
BIF files begin with the characters "BIF" to identify the file as a BIF file. Each line following this identifier defines a single field of information that would be found in a graphics file header. The syntax of these fields is a tag identifier followed by zero or one tag value. Lines that begin with "#" are considered as comments and ignored. And all lines in a BIF file are terminated with a newline character. The following is a BIF file generated from a source file name sample.jpg:
BIF filename sample.raw width 186 height 305 header 0 channels 3 order rgb leftpadding 0 rightpadding 0
We see that this BIF file begins with the identifier "BIF" and contains eight tags. From the tags we see that the bitmap data is stored in a file named sample.raw, the size of the bitmap is 186 by 305 pixels, the Raw file does not contain a header, the bitmap has three color channels that are stored in RGB order, and there is no padding before or after each scan line.
A complete explanation of each tag that may appear in a BIF file is as follows:
filename is the name of the file that contains the raw bitmap data. This file typically has the same name as the source file and the file extension of .raw. If the bitmap data is stored in three separate files, the filename tag will be repeated three times, one for each file storing the red, green, and blue components in RGB order. There is no default value for this field.
width and height are the width and height of the bitmap in pixels. There are no default values for these fields.
header is the number of bytes to skip over at the beginning of the Raw file. If the Raw file contains a header, it is typically not read and the header information in the BIF file is used instead. To skip over an HSI Raw file header, the header value in the BIF file will be 32 (the size of the HSI Raw file header in bytes). If no header is present in the Raw file, then the header value in the BIF file will be 0.
channels or planes is the number of color planes used to store the bitmap data. The valid tag values are 0 (1-bit black and white), 1 (gray scale), 2 (gray scale with alpha), 3 (RGB), and 4 (RGB with alpha). The default value is 0.
order is the order that the color channels are stored in the raw bitmap data. For one channel data the tag value will be "g" for gray. For two channel data (gray-scale with alpha), this value will be "ga" or "ag", depending upon the order of the channels. Three channel images are indicated by any sequence of "r", "g", and "b" (such as "rgb", "rbg", "grb", "brg", "gbr", and "brg"). Four channel (RGB with alpha) are any combination of "r", "g", "b", and "a". The defaults for one, two, three, and four channel data are "g", "ga", "rgb", and "rgba", respectively.
interleave is the type of pixel component interleaving used to store the bitmap data. A value of 0 indicates byte interleave, where each color component is stored by pixel (RGBRGBRGBRGB). A value of 1 indicates line interleaving, where all the red components of a scan line are stored first, then all the green components, and followed by the blue components (RRRGGGBBB RRRGGGBBB RRRGGGBBB). A value of 2 indicates plane interleaving, where all the red components for the entire bitmap are stored first, followed by all the green components, and then by all the blue components (RRRRRRRR GGGGGGGG BBBBBBBB).The default for this tag value is 0.
format is the format of the data in the Raw file. A value of "ascii" indicates that the bitmapped data is stored using comma-delimited values in an ASCII format. A value of "group3" indicates the bitmap data is compressed using CCITT Group 3 encoding. A value of "group4" indicates CCITT Group 4-compressed data. If this tag is not present, uncompressed binary data is assumed.
faxoptions are options that affect the decoding of facsimile-compressed data. The tag value "bitreversal" indicates that facsimile-compressed data (format tag values 3 and 4) are stored with the most-significant bit in each byte first. If this tag is not present, it is assumed that the least-significant bit in each byte is stored first.
leftpadding and rightpadding are the number of bytes to remove from the beginning and the end of a scan line respectively. The default for these tag values is 0.
upsidedown indicates that the bitmap is stored from the bottom of the raster up (the origin is in the lower left-hand corner of the display). If this tag is not present, it is assumed that the image is displayed starting at the upper left corner of the display. There is no associated value with this tag.
bitspersample is the number of bits per sample per pixel. Valid tag values are 1 (1-bit per sample, 8 samples per byte), 8 (one byte per sample), and 16 (two bytes per sample). The default is 8. Note that Image Alchemy scales 16-bit samples to 8-bits. Pixels 2- to 16-bits in size may be stored within a 16-bit sample value. Their default is 8.
bitorder specifies the order that bits are stored within a byte. The possible tag values are "msb" (most-significant bit first) and "lsb" (least-significant bit first). The default value is "msb".
byteorder indicates whether a 16-bit pixel value is stored using the little-endian (tag value of "intel") or the big-endian (tag value of "motorola") byte order. The default is "motorola".
signed indicates that 16-bit pixels are stored as signed values. The default is 16-bit pixels stored as unsigned values. There is no associated value with this tag.
BIF files are created using the -B option of the Image Alchemy program. In the following example, a TIFF file is converted to a BIF and a Raw file using Image Alchemy:
% alchemy sample.tif -B
The files sample.bif and sample.raw are produced. The Raw file contains the raw, unpacked bitmap data converted from the TIFF file, and the BIF file contains the header information necessary to describe the content of the Raw file. The contents of the BIF files appears as such:
BIF filename sample.raw width 32 height 32 header 0 channels 3 order rgb leftpadding 0 rightpadding 0
It is also possible to store each color plane of an RGB bitmap in a separate files. Given the command line:
% alchemy sample.tif -B 1
Three files named sample.r, sample.g, and sample.b would be created, containing the red, green, and blue pixel component data of the input file, respectively. The BIF file would look like this:
BIF filename sample.r filename sample.g filename sample.b width 32 height 32 header 0 channels 3 order rgb leftpadding 0 rightpadding 0
Using Image Alchemy, bitmap data may also be stored as an ASCII dump of pixel data into a single file (but not also into separate files by color plane, unfortunately) using the following command:
% alchemy sample.bmp -B 2
Here an 8-bit gray-scale BMP file is converted into a BIF file and a Raw file. The BIF file describes an ASCII format file, sample.raw, containing a 256x256x8 bitmap:
BIF filename sample.raw width 256 height 256 header 0 channels 1 order g leftpadding 0 rightpadding 0 format ascii
Part of the ASCII bitmap appears as such:
207, 0, 0, 0, 0, 0, 0,207 0, 68, 58, 58, 58, 58, 68, 0 58, 58, 58, 0, 0, 58, 58, 58 58, 0, 0, 17, 22, 0, 0, 58 0, 22, 22, 17, 17, 17, 58, 0 22, 22, 22, 22, 22, 0, 0, 0 28, 28, 28, 22, 0, 58, 58, 58 58, 58, 28, 0, 58, 58, 0, 0
ASCII Raw files are identical to binary Raw files, except that the pixel data is stored as comma-delimited decimal values, with each row terminated by a newline.
The three remaining Raw data formats, CCITT Group 3 and Group 4, and 1-bit packed pixels, are for 1-bit black and white data only. CCITT Group 3 is standard facsimile compression data, with each byte stored least-significant bit first, 12-bit end-of-line markers occurring before the first line and after every line except the last, and no byte alignment padding (fill bits) or Return To Control code. CCITT Group 4 data is also stored with each byte having its least-significant bit first by default. Packed data is stored eight pixels per byte and lines are padded out to a multiple of eight pixels per line.
PAL files describe the color palette information used to store the pixel colors for a bitmap. Image Alchemy can extract the color palette information from a supported graphics file and store it as a PAL file. The color palette information may then be changed and used to update the file, or the palette may be used to alter the existing palette of other graphics files. And because PAL files are simple ASCII text, they may also be created by hand using a text editor.
For example, if you wanted to read the color palette from a GIF file and save it to a PAL file, you would use the following command:
% alchemy sample.gif -l
This command reads the color palette information from the GIF file and saves it to the file sample.pal. If you wanted to convert a PCX file to TIFF, but substitute the color palette in the PAL file for the palette information in the PCX file, you would use the following command:
% alchemy sample.pcx -f sample.pal -t
This command will convert the file sample.pcx to sample.tif and subsitute the palette information in sample.pal for the palette data stored in sample.pcx.
And to replace the palette information in one TGA file with the palette information in another TGA file, you would could use the following commands:
% alchemy file2.tga file3 -F file1.tga -a
This command converts file2.tga to file3.tga and stores the palette information in file1.tga in file3.tga. This operation doesn't use a PAL file, but reading a color palette from one file and writing it to another is a very handy feature to have. And there are many other operations Image Alchemy can perform using color palettes.
PAL files are ASCII text and each line is terminated with a newline. The first line of the file is the characters "PAL" and is used to identify a PAL file. The next line contains the number of palette entries. This value may be in the range of 2 to 256 and also indicates the number of colors defined in the palette. Each remaining line contains three columns of data representing the red, green, and blue values for each entry. Each column value may be in the range of 0 to 255 decimal and the values are always stored in red, green, blue order. Any data that follows the three column values on a line is ignored.
A PAL file storing a two-color, black and white palette would appear as follows:
PAL 2 ; Number of entries (colors) 0 0 0 ; Black 255 255 255 ; White
An eight-color PAL file defining a few fundamental colors might appear as such:
PAL 8 0 0 0 ; Black 255 0 0 ; Red 0 255 0 ; Green 0 0 255 ; Blue 0 255 255 ; Cyan 255 0 255 ; Magenta 255 255 0 ; Yellow 255 255 255 ; White
And a gamut of 16 gray-scale values might appear as follows:
PAL 16 0 0 0 20 20 20 32 32 32 44 44 44 56 56 56 69 69 69 81 81 81 97 97 97 113 113 113 130 130 130 146 146 146 162 162 162 182 182 182 203 203 203 227 227 227 255 255 255
The BIF file format is described in the Image Alchemy PS User's Manual and is available from Handmade Software:
Handmade Software, Inc.
48860 Milmont Drive, Suite 106
Fremont, CA 94538
Voice: (800) 252-0101
Voice: (510) 252-0101
FAX: (510) 252-0909
BBS: (510) 252-0929
Email: support@handmadesw.com
WWW: http://www.handmadesw.com/
Copyright © 1996, 1994 O'Reilly & Associates, Inc. All Rights Reserved.