Home PageInfo About .Ico & .Cur Graphics FilesInfo About Anti-Virus8086 - Executive File InformationNetworking InfoDownload Executable Codes

Bitmap And RLE Graphics Files
Now we are going to discuss about the Windows Bitmap Picture Format which is widely used in GUI Application. Windows Paint Brush Offer you to create, edit and save bitmap pictures, but I don't think it provides full tools to play with. Windows Bitmap pictures can be stored in both compressed and uncompressed formats, but our windows paint brush application do not provide compressing facility. Poor colour handling is reported in windows paint brush application. Visual C++ Bitmap Editor provides some of these facilities; unfortunately it cannot handle true colour (24-Bit) images.
OK Let's Go Technical...
Although .BMP and .RLE Graphics file use different methods to store graphical data, they use the common bit-map header information. Some references divide the new .BMP or .RLE file header into two separate headers, one called the bit-map header and the other called the bit-map information header. The header is still the same, it is just divided into two sections, and each is assigned an arbitrary name. The header, when expressed as a C structure, looks like this :
struct
{
unsigned int IdKey;
unsigned long int FileSize;
unsigned int Reserved1,
Reserved2;
unsigned long int ImageDataOffset;
unsigned int HeaderSize,
Reserved3;
unsigned long int ImageWidth,
ImageHeight;
unsigned int NoOfPlanes,
BitsPerPixel;
unsigned long int CompressionMethod,
SizeOfBitMap,
XResolution,
YResolution,
NoOfColours,
NoOfSignificantColours;
} BmpRleHeader;
The IdKey parameter consists of the characters 42H and 4DH, which are the ASCII characters BM, indicating a bit-mapped file. These characters are same for .RLE files too.
The FileSize parameter is a long integer that contains the file size in bytes. You can probably get along without this parameter very well, but if you are generating .BMP or .RLE files, you need to include this parameter to make the files compatible with other software that uses these files.
The next two parameters (4 bytes) are reserved and should be set to zero. So far, Microsoft hasn't come up with anything to put in this space.
The next parameter, ImageDataOffset, is the number of bytes from the beginning of the file to the start of actual image data. This value is not the same for every .BMP and .RLE file because colour information of various sizes may reside between the header and the beginning of graphics data. You'll find this parameter useful in determining where you should position the file pointer to reading graphics data.
The next parameter, HeaderSize, is the size of the information header in bytes. For .BMP and .RLE files associated with Microsoft Windows versions 3.XX, this size is always 40 bytes (28H).
The parameters ImageWidth and ImageHeight are long integers giving the width and height of the graphic image in pixels.
The parameter NoOfPlanes is always set to 1, since all .BMP and .RLE files that presently exist use only one colour plane.
The parameter BitsPerPixel is the number of bits used to represent the colour of each pixel. Acceptable values are 1, 4, 8, and 24. The value 1 and 24 are not supported for .RLE files.
The parameter CompressionMethod value is 0 for uncompressed .BMP files, value 0 is not supported by .RLE files. If the value is 1 then it indicates compression of eight bits per pixel colour data, and 2 to indicate compression of four bits per pixel colour data. Although Windows Paint Brush Software can open compressed .BMP files, it does not support any new creation of compressed .BMP files.
The SizeOfBitMap parameter gives the size of the compressed data in bytes. This can be calculated indirectly from image dimensions in uncompressed .BMP files.
The XResolution and YResolution parameters are the horizontal and vertical resolutions, respectively, of the generating device in pixels per meter. They may prove useful in determining how to print or display the image. Again these values are not used by Windows Paint Brush Software.
The NoOfColours parameter is the number of colour used in the picture; if it is 0, the maximum number of available colours is used. The maximum number of colours is one shifted left by the number of BitsPerPixel parameter. Thus, eight bits per pixel would allow a maximum of 256 colours.
The NoOfSignificantColours gives the number of colours that appear frequently in the image. This parameter gives a clue as to how easily you can convert the picture for display in a mode that supports fewer colours than are used in the image. For example, if you have a 24-bit colour .BMP file whoseNoOfColours 2400, but whose NoOfSignificantColours is 230, you should get a very good picture representation with a 256-colour display.
Palettes Information...
Following the header, all 1,4, and 8 bit colour .BMP files have colour palette. and all 4 and 8 bit colour .RLE files have colour palette. length of colour palette is 8, 64 and 1024 for 1, 4 and 8 bit colour .BMP files. and length of colour palette is 64 and 1024 for 4 and 8 bit colour .RLE files. The first byte is the blue component of the colour, the second is the green component, the third is the red component, and the fourth is reserved---it is not used and should always be set to 0. Perhaps in some future version this byte may hold intensity information.
.BMP Image Data
Till now i have not started my research work on compressed .BMP files, So i exclude compressed .BMP files and i am going to provide information about uncompressed .BMP files, but surely i have provided information about compressed .RLE files. The .BMP image data is stored beginning at the bottom-left corner of the picture and working upward a line at a time. The 2 colour .BMP images(1-BitsPerPixel ) are stored sequentially, eight pixels per byte, that is each bit in the image data byte represent the colour of the index represented in colour palette. The 16 colour .BMP images(4-BitsPerPixel ) are stored sequentially, two pixels per byte, that is every four bit in the image data byte represent the colour of the index represented in colour palette. The 256 colour .BMP images(8-BitsPerPixel ) are stored sequentially, one pixel per byte, that is every byte in the image data represents the colour of the index represented in colour palette. The 16,777,216-colour (24-BitsPerPixel ) .BMP images are stored sequentially using three bytes per pixel. The 24-bit colour .BMP images give the colour of each pixel directly.
At the end of each row of pixel data in image data information, Microsoft has left some reserved bytes for padding. Padding is necessary because some Double Word-oriented implementations can't deal with odd-length scan row. Number of padding bytes that are inserted into bitmap image data depends on the ImageWidth and BitsPerPixel . For example, if you are trying to open 256(8 BitsPerPixel ) colour bitmap image, then divide the ImageWidth by 4. If the remainder is 1, then the number of padding bytes allocated is 3, this means at the end of each row of pixel data in image data information there are 3 padding bytes allocated, which are not useful for us. Number of padding bytes allocated with respect to the ImageWidth and BitsPerPixel are given in the following table.
24-BitsPerPixel , Divide ImageWidth By 4.
RemainderNumber Of Padding Bytes Allocated
00
11
22
33
8-BitsPerPixel , Divide ImageWidth By 4.
RemainderNumber Of Padding Bytes Allocated
00
13
22
31
4-BitsPerPixel , Divide ImageWidth By 8.
RemainderNumber Of Padding Bytes Allocated
00
13
23
32
42
51
61
70
1-BitPerPixel , Divide ImageWidth By 32.
RemainderNumber Of Padding Bytes Allocated
00
13
23
33
43
53
63
73
83
92
102
112
122
132
142
152
162
171
181
191
201
211
221
231
241
250
260
270
280
290
300
310
.RLE ( Run Length Encoded ) Image Data.
Life gets more complicated when I attempt to view .RLE files. The .RLE file has either 16 colours or 256 colours. First I'll look at the RLE scheme that is used. Each step in the decoding process begins by reading two bytes from the file. If the first byte is greater than 0, it represents the count of the number of pixels having the value represented by the second byte. If I'm working with a 256 - colour file, the second byte is the pixel value and is therefore displayed as many times as specified by the first byte number. If I'm working with a 16-colour file, the second byte represents two adjacent pixels. These pixels are extracted from the byte and displayed alternately until as many pixels have been displayed as specified by the number in the first byte. If the first byte is a 0 and is followed by another 0, it signifies that the end of a line has been reached. If the first byte is a 0 and the second byte is a 1, it signifies the end of video image. If the first byte is a 0 and the second byte is a 2, it signifies a data position shift. If the first byte is 0 and the second byte is greater than 2, the second byte represents the number of pixels that are to follow in a literal string. For 256-colour files, this string consists of a number of bytes equal to the specified number, each of which is a pixel to be displayed. For 16-colour files, this string consists of a number of bytes equal to half the specified number, each containing two pixels. The literal string must end on a word boundary; if not, I need to read another byte from the file, which has been inserted as padding. No action needs to be taken on this byte; reading it just gets me to the proper place for the next read. The way in which the RLE takes place assures that every line ends on a word boundary, so I don't need to worry about that.