graphics file formats

this topic describes the graphics-file formats used by the microsoft windows
operating system. graphics files include bitmap files, icon-resource files,
and cursor-resource files.

bitmap-file formats

windows bitmap files are stored in a device-independent bitmap (dib) format
that allows windows to display the bitmap on any type of display device. the
term "device independent" means that the bitmap specifies pixel color in a
form independent of the method used by a display to represent color. the
default filename extension of a windows dib file is .bmp.

bitmap-file structures

each bitmap file contains a bitmap-file header, a bitmap-information header,
a color table, and an array of bytes that defines the bitmap bits. the file
has the following form:

bitmapfileheader bmfh;
bitmapinfoheader bmih;
rgbquad acolors[];
byte abitmapbits[];

the bitmap-file header contains information about the type, size, and layout
of a device-independent bitmap file. the header is defined as a
bitmapfileheader structure.

the bitmap-information header, defined as a bitmapinfoheader structure,
specifies the dimensions, compression type, and color format for the bitmap.

the color table, defined as an array of rgbquad structures, contains as many
elements as there are colors in the bitmap. the color table is not present
for bitmaps with 24 color bits because each pixel is represented by 24-bit
red-green-blue (rgb) values in the actual bitmap data area. the colors in the
table should appear in order of importance. this helps a display driver
render a bitmap on a device that cannot display as many colors as there are
in the bitmap. if the dib is in windows version 3.0 or later format, the
driver can use the biclrimportant member of the bitmapinfoheader structure to
determine which colors are important.

the bitmapinfo structure can be used to represent a combined
bitmap-information header and color table. the bitmap bits, immediately
following the color table, consist of an array of byte values representing
consecutive rows, or "scan lines," of the bitmap. each scan line consists of
consecutive bytes representing the pixels in the scan line, in left-to-right
order. the number of bytes representing a scan line depends on the color
format and the width, in pixels, of the bitmap. if necessary, a scan line
must be zero-padded to end on a 32-bit boundary. however, segment boundaries
can appear anywhere in the bitmap. the scan lines in the bitmap are stored
from bottom up. this means that the first byte in the array represents the
pixels in the lower-left corner of the bitmap and the last byte represents
the pixels in the upper-right corner.

the bibitcount member of the bitmapinfoheader structure determines the number
of bits that define each pixel and the maximum number of colors in the
bitmap. these members can have any of the following values:

value meaning

1 bitmap is monochrome and the color table contains two entries. each
bit in the bitmap array represents a pixel. if the bit is clear, the pixel is
displayed with the color of the first entry in the color table. if the bit is
set, the pixel has the color of the second entry in the table.

4 bitmap has a maximum of 16 colors. each pixel in the bitmap is
represented by a 4-bit index into the color table. for example, if the first
byte in the bitmap is 0x1f, the byte represents two pixels. the first pixel
contains the color in the second table entry, and the second pixel contains
the color in the sixteenth table entry.

8 bitmap has a maximum of 256 colors. each pixel in the bitmap is
represented by a 1-byte index into the color table. for example, if the first
byte in the bitmap is 0x1f, the first pixel has the color of the
thirty-second table entry.

24 bitmap has a maximum of 2^24 colors. the bmicolors (or bmcicolors)
member is null, and each 3-byte sequence in the bitmap array represents the
relative intensities of red, green, and blue, respectively, for a pixel.

the biclrused member of the bitmapinfoheader structure specifies the number
of color indexes in the color table actually used by the bitmap. if the
biclrused member is set to zero, the bitmap uses the maximum number of colors
corresponding to the value of the bibitcount member. an alternative form of
bitmap file uses the bitmapcoreinfo, bitmapcoreheader, and rgbtriple
structures.

bitmap compression

windows versions 3.0 and later support run-length encoded (rle) formats for
compressing bitmaps that use 4 bits per pixel and 8 bits per pixel.
compression reduces the disk and memory storage required for a bitmap.

compression of 8-bits-per-pixel bitmaps

when the bicompression member of the bitmapinfoheader structure is set to
bi_rle8, the dib is compressed using a run-length encoded format for a
256-color bitmap. this format uses two modes: encoded mode and absolute mode.
both modes can occur anywhere throughout a single bitmap.

encoded mode

a unit of information in encoded mode consists of two bytes. the first byte
specifies the number of consecutive pixels to be drawn using the color index
contained in the second byte. the first byte of the pair can be set to zero
to indicate an escape that denotes the end of a line, the end of the bitmap,
or a delta. the interpretation of the escape depends on the value of the
second byte of the pair, which must be in the range 0x00 through 0x02.
following are the meanings of the escape values that can be used in the
second byte:

second byte meaning

0 end of line.
1 end of bitmap.
2 delta. the two bytes following the escape contain unsigned values
indicating the horizontal and vertical offsets of the next pixel from the
current position.

absolute mode

absolute mode is signaled by the first byte in the pair being set to zero and
the second byte to a value between 0x03 and 0xff. the second byte represents
the number of bytes that follow, each of which contains the color index of a
single pixel. each run must be aligned on a word boundary. following is an
example of an 8-bit rle bitmap (the two-digit hexadecimal values in the
second column represent a color index for a single pixel):

compressed data expanded data

03 04 04 04 04
05 06 06 06 06 06 06
00 03 45 56 67 00 45 56 67
02 78 78 78
00 02 05 01 move 5 right and 1 down
02 78 78 78
00 00 end of line
09 1e 1e 1e 1e 1e 1e 1e 1e 1e 1e
00 01 end of rle bitmap

compression of 4-bits-per-pixel bitmaps

when the bicompression member of the bitmapinfoheader structure is set to
bi_rle4, the dib is compressed using a run-length encoded format for a
16-color bitmap. this format uses two modes: encoded mode and absolute mode.

encoded mode

a unit of information in encoded mode consists of two bytes. the first byte
of the pair contains the number of pixels to be drawn using the color indexes
in the second byte.

the second byte contains two color indexes, one in its high-order nibble
(that is, its low-order 4 bits) and one in its low-order nibble.

the first pixel is drawn using the color specified by the high-order nibble,
the second is drawn using the color in the low-order nibble, the third is
drawn with the color in the high-order nibble, and so on, until all the
pixels specified by the first byte have been drawn.

the first byte of the pair can be set to zero to indicate an escape that
denotes the end of a line, the end of the bitmap, or a delta. the
interpretation of the escape depends on the value of the second byte of the
pair. in encoded mode, the second byte has a value in the range 0x00 through
0x02. the meaning of these values is the same as for a dib with 8 bits per
pixel.

absolute mode

in absolute mode, the first byte contains zero, the second byte contains the
number of color indexes that follow, and subsequent bytes contain color
indexes in their high- and low-order nibbles, one color index for each pixel.
each run must be aligned on a word boundary.

following is an example of a 4-bit rle bitmap (the one-digit hexadecimal
values in the second column represent a color index for a single pixel):

compressed data expanded data

03 04 0 4 0
05 06 0 6 0 6 0
00 06 45 56 67 00 4 5 5 6 6 7
04 78 7 8 7 8
00 02 05 01 move 5 right and 1 down
04 78 7 8 7 8
00 00 end of line
09 1e 1 e 1 e 1 e 1 e 1
00 01 end of rle bitmap

bitmap example

the following example is a text dump of a 16-color bitmap (4 bits per pixel):

win3dibfile
bitmapfileheader
type 19778
size 3118
reserved1 0
reserved2 0
offsetbits 118
bitmapinfoheader
size 40
width 80
height 75
planes 1
bitcount 4
compression 0
sizeimage 3000

xpelspermeter 0
ypelspermeter 0
colorsused 16
colorsimportant 16
win3colortable
blue green red unused
[00000000] 84 252 84 0
[00000001] 252 252 84 0
[00000002] 84 84 252 0
[00000003] 252 84 252 0
[00000004] 84 252 252 0
[00000005] 252 252 252 0
[00000006] 0 0 0 0
[00000007] 168 0 0 0
[00000008] 0 168 0 0
[00000009] 168 168 0 0
[0000000a] 0 0 168 0
[0000000b] 168 0 168 0
[0000000c] 0 168 168 0
[0000000d] 168 168 168 0
[0000000e] 84 84 84 0
[0000000f] 252 84 84 0
image
.
. bitmap data

[此贴子已经被作者于2006-12-22 11:14:48编辑过]

icon-resource file format

an icon-resource file contains image data for icons used by windows
applications. the file consists of an icon directory identifying the number
and types of icon images in the file, plus one or more icon images. the
default filename extension for an icon-resource file is .ico.

icon directory

each icon-resource file starts with an icon directory. the icon directory,
defined as an icondir structure, specifies the number of icons in the
resource and the dimensions and color format of each icon image. the icondir
structure has the following form:

typedef struct icondir {
word idreserved;
word idtype;
word idcount;
icondirentry identries[1];
} iconheader;

following are the members in the icondir structure:

idreserved reserved; must be zero.
idtype specifies the resource type. this member is set to 1.
idcount specifies the number of entries in the directory.
identries specifies an array of icondirentry structures containing
information about individual icons. the idcount member specifies the number
of structures in the array.

the icondirentry structure specifies the dimensions and color format for an
icon. the structure has the following form:

struct icondirectoryentry {
byte bwidth;
byte bheight;
byte bcolorcount;
byte breserved;
word wplanes;
word wbitcount;
dword dwbytesinres;
dword dwimageoffset;
};

following are the members in the icondirentry structure:

bwidth specifies the width of the icon, in pixels. acceptable values
are 16, 32, and 64.

bheight specifies the height of the icon, in pixels. acceptable
values are 16, 32, and 64.

bcolorcount specifies the number of colors in the icon. acceptable values
are 2, 8, and 16.

breserved reserved; must be zero.
wplanes specifies the number of color planes in the icon bitmap.
wbitcount specifies the number of bits in the icon bitmap.
dwbytesinres specifies the size of the resource, in bytes.
dwimageoffset specifies the offset, in bytes, from the beginning of the
file to the icon image.

icon image

each icon-resource file contains one icon image for each image identified in
the icon directory. an icon image consists of an icon-image header, a color
table, an xor mask, and an and mask. the icon image has the following form:

bitmapinfoheader icheader;
rgbquad iccolors[];
byte icxor[];
byte icand[];

the icon-image header, defined as a bitmapinfoheader structure, specifies the
dimensions and color format of the icon bitmap. only the bisize through
bibitcount members and the bisizeimage member are used. all other members
(such as bicompression and biclrimportant) must be set to zero.

the color table, defined as an array of rgbquad structures, specifies the
colors used in the xor mask. as with the color table in a bitmap file, the
bibitcount member in the icon-image header determines the number of elements
in the array. for more information about the color table, see section 1.1,
"bitmap-file formats."

the xor mask, immediately following the color table, is an array of byte
values representing consecutive rows of a bitmap. the bitmap defines the
basic shape and color of the icon image. as with the bitmap bits in a bitmap
file, the bitmap data in an icon-resource file is organized in scan lines,
with each byte representing one or more pixels, as defined by the color
format. for more information about these bitmap bits, see section 1.1,
"bitmap-file formats."

the and mask, immediately following the xor mask, is an array of byte values,
representing a monochrome bitmap with the same width and height as the xor
mask. the array is organized in scan lines, with each byte representing 8
pixels.

when windows draws an icon, it uses the and and xor masks to combine the icon
image with the pixels already on the display surface. windows first applies
the and mask by using a bitwise and operation; this preserves or removes
existing pixel color. windows then applies the xor mask by using a bitwise
xor operation. this sets the final color for each pixel.

the following illustration shows the xor and and masks that create a
monochrome icon (measuring 8 pixels by 8 pixels) in the form of an uppercase
k:

windows icon selection

windows detects the resolution of the current display and matches it against
the width and height specified for each version of the icon image. if windows
determines that there is an exact match between an icon image and the current
device, it uses the matching image. otherwise, it selects the closest match
and stretches the image to the proper size.

if an icon-resource file contains more than one image for a particular
resolution, windows uses the icon image that most closely matches the color
capabilities of the current display. if no image matches the device
capabilities exactly, windows selects the image that has the greatest number
of colors without exceeding the number of display colors. if all images
exceed the color capabilities of the current display, windows uses the icon
image with the least number of colors.

cursor-resource file format

a cursor-resource file contains image data for cursors used by windows
applications. the file consists of a cursor directory identifying the number
and types of cursor images in the file, plus one or more cursor images. the
default filename extension for a cursor-resource file is .cur.

cursor directory

each cursor-resource file starts with a cursor directory. the cursor
directory, defined as a cursordir structure, specifies the number of cursors
in the file and the dimensions and color format of each cursor image. the
cursordir structure has the following form:

typedef struct _cursordir {
word cdreserved;
word cdtype;
word cdcount;
cursordirentry cdentries[];
} cursordir;

following are the members in the cursordir structure:

cdreserved reserved; must be zero.
cdtype specifies the resource type. this member must be set to 2.
cdcount specifies the number of cursors in the file.
cdentries specifies an array of cursordirentry structures containing
information about individual cursors. the cdcount member specifies the number
of structures in the array.

a cursordirentry structure specifies the dimensions and color format of a
cursor image. the structure has the following form:

typedef struct _cursordirentry {
byte bwidth;
byte bheight;
byte bcolorcount;
byte breserved;
word wxhotspot;
word wyhotspot;
dword lbytesinres;
dword dwimageoffset;
} cursordirentry;

following are the members in the cursordirentry structure:

bwidth specifies the width of the cursor, in pixels.
bheight specifies the height of the cursor, in pixels.
bcolorcount reserved; must be zero.
breserved reserved; must be zero.
wxhotspot specifies the x-coordinate, in pixels, of the hot spot.
wyhotspot specifies the y-coordinate, in pixels, of the hot spot.
lbytesinres specifies the size of the resource, in bytes.
dwimageoffset specifies the offset, in bytes, from the start of the file to
the cursor image.

cursor image

each cursor-resource file contains one cursor image for each image identified
in the cursor directory. a cursor image consists of a cursor-image header, a
color table, an xor mask, and an and mask. the cursor image has the following
form:

bitmapinfoheader crheader;
rgbquad crcolors[];
byte crxor[];
byte crand[];

the cursor hot spot is a single pixel in the cursor bitmap that windows uses
to track the cursor. the crxhotspot and cryhotspot members specify the x- and
y-coordinates of the cursor hot spot. these coordinates are 16-bit integers.

the cursor-image header, defined as a bitmapinfoheader structure, specifies
the dimensions and color format of the cursor bitmap. only the bisize through
bibitcount members and the bisizeimage member are used. the biheight member
specifies the combined height of the xor and and masks for the cursor. this
value is twice the height of the xor mask. the biplanes and bibitcount
members must be 1. all other members (such as bicompression and
biclrimportant) must be set to zero.

the color table, defined as an array of rgbquad structures, specifies the
colors used in the xor mask. for a cursor image, the table contains exactly
two structures, since the bibitcount member in the cursor-image header is
always 1.

the xor mask, immediately following the color table, is an array of byte
values representing consecutive rows of a bitmap. the bitmap defines the
basic shape and color of the cursor image. as with the bitmap bits in a
bitmap file, the bitmap data in a cursor-resource file is organized in scan
lines, with each byte representing one or more pixels, as defined by the
color format. for more information about these bitmap bits, see section 1.1,
"bitmap-file formats."

the and mask, immediately following the xor mask, is an array of byte values
representing a monochrome bitmap with the same width and height as the xor
mask. the array is organized in scan lines, with each byte representing 8
pixels.

when windows draws a cursor, it uses the and and xor masks to combine the
cursor image with the pixels already on the display surface. windows first
applies the and mask by using a bitwise and operation; this preserves or
removes existing pixel color. window then applies the xor mask by using a
bitwise xor operation. this sets the final color for each pixel.

the following illustration shows the xor and the and masks that create a
cursor (measuring 8 pixels by 8 pixels) in the form of an arrow:

following are the bit-mask values necessary to produce black, white,
inverted, and transparent results:

pixel result and maskxor mask

black 0 0
white 0 1
transparent 1 0
inverted1 1

windows cursor selection

if a cursor-resource file contains more than one cursor image, windows
determines the best match for a particular display by examining the width and
height of the cursor images.

==============================================================================

bitmapfileheader (3.0)

typedef struct tagbitmapfileheader { /* bmfh */
uint bftype;
dword bfsize;
uint bfreserved1;
uint bfreserved2;
dword bfoffbits;
} bitmapfileheader;

the bitmapfileheader structure contains information about the type, size, and
layout of a device-independent bitmap (dib) file.

member description

bftype specifies the type of file. this member must be bm.
bfsize specifies the size of the file, in bytes.
bfreserved1 reserved; must be set to zero.
bfreserved2 reserved; must be set to zero.
bfoffbits specifies the byte offset from the bitmapfileheader structure
to the actual bitmap data in the file.

comments

a bitmapinfo or bitmapcoreinfo structure immediately follows the
bitmapfileheader structure in the dib file.

see also

bitmapcoreinfo, bitmapinfo

==============================================================================
bitmapinfo (3.0)

typedef struct tagbitmapinfo { /* bmi */
bitmapinfoheader bmiheader;
rgbquad bmicolors[1];
} bitmapinfo;

the bitmapinfo structure fully defines the dimensions and color information
for a windows 3.0 or later device-independent bitmap (dib).

member description

bmiheader specifies a bitmapinfoheader structure that contains
information about the dimensions and color format of a dib.

bmicolors specifies an array of rgbquad structures that define the
colors in the bitmap.

comments

a windows 3.0 or later dib consists of two distinct parts: a bitmapinfo
structure, which describes the dimensions and colors of the bitmap, and an
array of bytes defining the pixels of the bitmap. the bits in the array are
packed together, but each scan line must be zero-padded to end on a long
boundary. segment boundaries, however, can appear anywhere in the bitmap. the
origin of the bitmap is the lower-left corner.

the bibitcount member of the bitmapinfoheader structure determines the number
of bits which define each pixel and the maximum number of colors in the
bitmap. this member may be set to any of the following values:

value meaning

1 the bitmap is monochrome, and the bmcicolors member must contain two
entries. each bit in the bitmap array represents a pixel. if the bit is
clear, the pixel is displayed with the color of the first entry in the
bmcicolors table. if the bit is set, the pixel has the color of the second
entry in the table.

4 the bitmap has a maximum of 16 colors, and the bmcicolors member
contains 16 entries. each pixel in the bitmap is represented by a four-bit
index into the color table.

for example, if the first byte in the bitmap is 0x1f, the byte represents two
pixels. the first pixel contains the color in the second table entry, and the
second pixel contains the color in the sixteenth table entry.

8 the bitmap has a maximum of 256 colors, and the bmcicolors member
contains 256 entries. in this case, each byte in the array represents a
single pixel.

24 the bitmap has a maximum of 2^24 colors. the bmcicolors member is
null, and each 3-byte sequence in the bitmap array represents the relative
intensities of red, green, and blue, respectively, of a pixel.

the biclrused member of the bitmapinfoheader structure specifies the number
of color indexes in the color table actually used by the bitmap. if the
biclrused member is set to zero, the bitmap uses the maximum number of colors
corresponding to the value of the bibitcount member.

the colors in the bmicolors table should appear in order of importance.
alternatively, for functions that use dibs, the bmicolors member can be an
array of 16-bit unsigned integers that specify an index into the currently
realized logical palette instead of explicit rgb values. in this case, an
application using the bitmap must call dib functions with the wusage
parameter set to dib_pal_colors.

note: the bmicolors member should not contain palette indexes if the bitmap
is to be stored in a file or transferred to another application. unless the
application uses the bitmap exclusively and under its complete control, the
bitmap color table should contain explicit rgb values.

see also

bitmapinfoheader, rgbquad

==============================================================================
bitmapinfoheader (3.0)

typedef struct tagbitmapinfoheader { /* bmih */
dword bisize;
long biwidth;
long biheight;
word biplanes;
word bibitcount;
dword bicompression;
dword bisizeimage;
long bixpelspermeter;
long biypelspermeter;
dword biclrused;
dword biclrimportant;
} bitmapinfoheader;

the bitmapinfoheader structure contains information about the dimensions and
color format of a windows 3.0 or later device-independent bitmap (dib).

member description

bisize specifies the number of bytes required by the
bitmapinfoheader structure.

biwidth specifies the width of the bitmap, in pixels.
biheightspecifies the height of the bitmap, in pixels.

biplanesspecifies the number of planes for the target device. this
member must be set to 1.

bibitcount specifies the number of bits per pixel. this value must be 1,
4, 8, or 24.

bicompression specifies the type of compression for a compressed bitmap. it
can be one of the following values:

value meaning

bi_rgb specifies that the bitmap is not compressed.

bi_rle8 specifies a run-length encoded format for bitmaps with 8 bits
per pixel. the compression format is a 2-byte format consisting of a count
byte followed by a byte containing a color index. for more information, see
the following comments section.

bi_rle4 specifies a run-length encoded format for bitmaps with 4 bits
per pixel. the compression format is a 2-byte format consisting of a count
byte followed by two word-length color indexes. for more information, see
the following comments section.

bisizeimage specifies the size, in bytes, of the image. it is valid to
set this member to zero if the bitmap is in the bi_rgb format.

bixpelspermeter specifies the horizontal resolution, in pixels per meter, of
the target device for the bitmap. an application can use this value to select
a bitmap from a resource group that best matches the characteristics of the
current device.

biypelspermeter specifies the vertical resolution, in pixels per meter, of
the target device for the bitmap.

biclrused specifies the number of color indexes in the color table
actually used by the bitmap. if this value is zero, the bitmap uses the
maximum number of colors corresponding to the value of the bibitcount member.
for more information on the maximum sizes of the color table, see the
description of the bitmapinfo structure earlier in this topic.

if the biclrused member is nonzero, it specifies the actual number of colors
that the graphics engine or device driver will access if the bibitcount
member is less than 24. if bibitcount is set to 24, biclrused specifies the
size of the reference color table used to optimize performance of windows
color palettes. if the bitmap is a packed bitmap (that is, a bitmap in which
the bitmap array immediately follows the bitmapinfo header and which is
referenced by a single pointer), the biclrused member must be set to zero or
to the actual size of the color table.

biclrimportant specifies the number of color indexes that are considered
important for displaying the bitmap. if this value is zero, all colors are
important.

comments

the bitmapinfo structure combines the bitmapinfoheader structure and a color
table to provide a complete definition of the dimensions and colors of a
windows 3.0 or later dib. for more information about specifying a windows 3.0
dib, see the description of the bitmapinfo structure.

an application should use the information stored in the bisize member to
locate the color table in a bitmapinfo structure as follows:

pcolor = ((lpstr) pbitmapinfo + (word) (pbitmapinfo->bmiheader.bisize))

windows supports formats for compressing bitmaps that define their colors
with 8 bits per pixel and with 4 bits per pixel. compression reduces the disk
and memory storage required for the bitmap. the following paragraphs describe
these formats.

bi_rle8

when the bicompression member is set to bi_rle8, the bitmap is compressed
using a run-length encoding format for an 8-bit bitmap. this format may be
compressed in either of two modes: encoded and absolute. both modes can occur
anywhere throughout a single bitmap.

encoded mode consists of two bytes: the first byte specifies the number of
consecutive pixels to be drawn using the color index contained in the second
byte. in addition, the first byte of the pair can be set to zero to indicate
an escape that denotes an end of line, end of bitmap, or a delta. the
interpretation of the escape depends on the value of the second byte of the
pair. the following list shows the meaning of the second byte:

value meaning

0 end of line.
1 end of bitmap.
2 delta. the two bytes following the escape contain unsigned values
indicating the horizontal and vertical offset of the next pixel from the
current position.

absolute mode is signaled by the first byte set to zero and the second byte
set to a value between 0x03 and 0xff. in absolute mode, the second byte
represents the number of bytes that follow, each of which contains the color
index of a single pixel. when the second byte is set to 2 or less, the escape
has the same meaning as in encoded mode. in absolute mode, each run must be
aligned on a word boundary. the following example shows the hexadecimal
values of an 8-bit compressed bitmap:

03 04 05 06 00 03 45 56 67 00 02 78 00 02 05 01
02 78 00 00 09 1e 00 01

this bitmap would expand as follows (two-digit values represent a color index
for a single pixel):

04 04 04
06 06 06 06 06
45 56 67
78 78
move current position 5 right and 1 down
78 78
end of line
1e 1e 1e 1e 1e 1e 1e 1e 1e
end of rle bitmap

bi_rle4

when the bicompression member is set to bi_rle4, the bitmap is compressed
using a run-length encoding (rle) format for a 4-bit bitmap, which also uses
encoded and absolute modes. in encoded mode, the first byte of the pair
contains the number of pixels to be drawn using the color indexes in the
second byte. the second byte contains two color indexes, one in its
high-order nibble (that is, its low-order four bits) and one in its low-order
nibble. the first of the pixels is drawn using the color specified by the
high-order nibble, the second is drawn using the color in the low-order
nibble, the third is drawn with the color in the high-order nibble, and so
on, until all the pixels specified by the first byte have been drawn. in
absolute mode, the first byte contains zero, the second byte contains the
number of color indexes that follow, and subsequent bytes contain color
indexes in their high- and low-order nibbles, one color index for each pixel.
in absolute mode, each run must be aligned on a word boundary. the
end-of-line, end-of-bitmap, and delta escapes also apply to bi_rle4.

the following example shows the hexadecimal values of a 4-bit compressed
bitmap:

03 04 05 06 00 06 45 56 67 00 04 78 00 02 05 01
04 78 00 00 09 1e 00 01

this bitmap would expand as follows (single-digit values represent a color
index for a single pixel):

0 4 0
0 6 0 6 0
4 5 5 6 6 7
7 8 7 8
move current position 5 right and 1 down
7 8 7 8
end of line
1 e 1 e 1 e 1 e 1
end of rle bitmap

see also

bitmapinfo

==============================================================================
rgbquad (3.0)

typedef struct tagrgbquad { /* rgbq */
byte rgbblue;
byte rgbgreen;
byte rgbred;
byte rgbreserved;
} rgbquad;

the rgbquad structure describes a color consisting of relative intensities of
red, green, and blue. the bmicolors member of the bitmapinfo structure
consists of an array of rgbquad structures.

member description

rgbblue specifies the intensity of blue in the color.
rgbgreenspecifies the intensity of green in the color.
rgbred specifies the intensity of red in the color.
rgbreserved not used; must be set to zero.

see also

bitmapinfo

==============================================================================
rgb (2.x)

colorref rgb(cred, cgreen, cblue)

byte cred; /* red component of color */
byte cgreen; /* green component of color */
byte cblue; /* blue component of color */

the rgb macro selects an rgb color based on the parameters supplied and the
color capabilities of the output device.

parameter description

cred specifies the intensity of the red color field.
cgreen specifies the intensity of the green color field.
cblue specifies the intensity of the blue color field.

returns

the return value specifies the resultant rgb color.

comments

the intensity for each argument can range from 0 through 255. if all three
intensities are specified as zero, the result is black. if all three
intensities are specified as 255, the result is white.

comments

the rgb macro is defined in windows.h as follows:

#define rgb(r,g,b) ((colorref)(((byte)(r)|((word)(g)<<8))| \
(((dword)(byte)(b))<<16)))

see also

getbvalue, getgvalue, getrvalue, paletteindex, palettergb

bitmapcoreinfo (3.0)

typedef struct tagbitmapcoreinfo { /* bmci */
bitmapcoreheader bmciheader;
rgbtriple bmcicolors[1];
} bitmapcoreinfo;

the bitmapcoreinfo structure fully defines the dimensions and color
information for a device-independent bitmap (dib). windows applications
should use the bitmapinfo structure instead of bitmapcoreinfo whenever
possible.

member description

bmciheader specifies a bitmapcoreheader structure that contains
information about the dimensions and color format of a dib.

bmcicolors specifies an array of rgbtriple structures that define the
colors in the bitmap.

comments

the bitmapcoreinfo structure describes the dimensions and colors of a bitmap.
it is followed immediately in memory by an array of bytes which define the
pixels of the bitmap. the bits in the array are packed together, but each
scan line must be zero-padded to end on a long boundary. segment boundaries,
however, can appear anywhere in the bitmap. the origin of the bitmap is the
lower-left corner.

the bcbitcount member of the bitmapcoreheader structure determines the number
of bits that define each pixel and the maximum number of colors in the
bitmap. this member may be set to any of the following values:

value meaning

1 the bitmap is monochrome, and the bmcicolors member must contain two
entries. each bit in the bitmap array represents a pixel. if the bit is
clear, the pixel is displayed with the color of the first entry in the
bmcicolors table. if the bit is set, the pixel has the color of the second
entry in the table.

4 the bitmap has a maximum of 16 colors, and the bmcicolors member
contains 16 entries. each pixel in the bitmap is represented by a four-bit
index into the color table.

for example, if the first byte in the bitmap is 0x1f, the byte represents two
pixels. the first pixel contains the color in the second table entry, and the
second pixel contains the color in the sixteenth table entry.

8 the bitmap has a maximum of 256 colors, and the bmcicolors member
contains 256 entries. in this case, each byte in the array represents a
single pixel.

24 the bitmap has a maximum of 2^24 colors. the bmcicolors member is
null, and each 3-byte sequence in the bitmap array represents the relative
intensities of red, green, and blue, respectively, of a pixel.

the colors in the bmcicolors table should appear in order of importance.
alternatively, for functions that use dibs, the bmcicolors member can be an
array of 16-bit unsigned integers that specify an index into the currently
realized logical palette instead of explicit rgb values. in this case, an
application using the bitmap must call dib functions with the wusage
parameter set to dib_pal_colors.

note: the bmcicolors member should not contain palette indexes if the
bitmap is to be stored in a file or transferred to another application.
unless the application uses the bitmap exclusively and under its complete
control, the bitmap color table should contain explicit rgb values.

see also

bitmapinfo, bitmapcoreheader, rgbtriple

==============================================================================
bitmapcoreheader (3.0)

typedef struct tagbitmapcoreheader { /* bmch */
dword bcsize;
short bcwidth;
short bcheight;
word bcplanes;
word bcbitcount;
} bitmapcoreheader;

the bitmapcoreheader structure contains information about the dimensions and
color format of a device-independent bitmap (dib). windows applications
should use the bitmapinfoheader structure instead of bitmapcoreheader
whenever possible.

member description

bcsize specifies the number of bytes required by the
bitmapcoreheader structure.

bcwidth specifies the width of the bitmap, in pixels.
bcheightspecifies the height of the bitmap, in pixels.

bcplanesspecifies the number of planes for the target device. this
member must be set to 1.

bcbitcount specifies the number of bits per pixel. this value must be 1,
4, 8, or 24.

comments

the bitmapcoreinfo structure combines the bitmapcoreheader structure and a
color table to provide a complete definition of the dimensions and colors of
a dib. see the description of the bitmapcoreinfo structure for more
information about specifying a dib.

an application should use the information stored in the bcsize member to
locate the color table in a bitmapcoreinfo structure with a method such as
the following:

lpcolor = ((lpstr) pbitmapcoreinfo + (uint) (pbitmapcoreinfo->bcsize))

see also

bitmapcoreinfo, bitmapinfoheader, bitmapinfoheader

=============================================================================
rgbtriple (3.0)

typedef struct tagrgbtriple { /* rgbt */
byte rgbtblue;
byte rgbtgreen;
byte rgbtred;
} rgbtriple;

the rgbtriple structure describes a color consisting of relative intensities
of red, green, and blue. the bmcicolors member of the bitmapcoreinfo
structure consists of an array of rgbtriple structures. windows applications
should use the bitmapinfo structure instead of bitmapcoreinfo whenever
possible. the bitmapinfo structure uses an rgbquad structure instead of the
rgbtriple structure.

member description

rgbtbluespecifies the intensity of blue in the color.
rgbtgreen specifies the intensity of green in the color.
rgbtred specifies the intensity of red in the color.

see also

bitmapcoreinfo, bitmapinfo, rgbquad

  好象看天书

拿去叻````用繙譯軟件繙譯一下    ````

一般的图像文件结构都包含有文件头、文件体和文件尾等三部分（图06-05-1）。

软件ID

软件版本号

图像分辨率

图像尺寸

图像深度

彩色类型

编码方式

压缩算法

图像数据

彩色变换表

用户名

注释

开发日期

工作时间


文件头的主要内容包括产生或编辑该图像文件的软件的信息以及图像本身的参数。这些参数必须完整地描述图像数据的所有特征，因此是图像文件中的关键数据。当然，根据不同的文件，有的参数是可选的，如压缩算法，有的文件无压缩，有的文件可选择多种方法压缩。

　

文件体主要包括图像数据以及颜色变换查找表或调色板数据。这部分是文件的主体，对文件容量的大小起决定作用。如果是真彩色图像，则无颜色变换查找表或调色板数据，对于256色的调色板，每种颜色值用24 bit表示，则调色板的数据长度为256×3（Byte）。

　

文件尾可包含一些用户信息。文件尾是可选项，有的文件格式不包括这部分内容。由于文件体数据量较之文件头与文件尾要大得多，而文件体中颜色变换表或调色板所占用的空间一般也比图像数据小得多，因此图像文件的容量一般能够表示图像数据的容量（压缩或无压缩）。

图06-05-1 图像文件结构

当然，图06-05-1只是一个大概的图像文件结构说明，实际的结构根据不同的格式其中的条目要细得多，结构也复杂得多，各个条目所占空间及条目间的排列顺序也大不相同。目前还没有非常统一的图像文件格式。但大多数图像处理软件都与数种图像文件格式相兼容，也即可读取多种不同格式的图像文件。这样，不同的图像格式间可相互转换。当然，还有专门的图像格式转换软件，用于各种图像格式间的转换。

二．常用图像文件格式

几乎所有的图像文件都采用各自简化的格式名作为文件扩展名。从扩展名就可知道这幅图像是按什么格式存贮的，应该用什么样的软件去读 / 写。

（一）BMP格式

BMP是一种与硬件设备无关的图像文件格式，使用非常广。它采用位映射存贮格式，除了图像深度可选以外，不采用其他任何压缩，因此，BMP文件所占用的空间很大。BMP文件的图像深度可选1 bit、4 bit、8 bit及24 bit。BMP文件存储数据时，图像的扫描方式是按从左到右、从下到上的顺序。

（二）PCX格式

这是PC 画笔的图像文件格式。PCX的图像深度可选为1、4、8 bit。由于这种文件格式出现较早，它不支持真彩色。PCX文件采用RLE行程编码，文件体中存放的是压缩后的图像数据。因此，将采集到的图像数据写成PCX文件格式时，要对其进行RLE编码；而读取一个PCX文件时首先要对其进行RLE解码，才能进一步显示和处理。

（三）TIFF格式

TIFF（Tag Image File Format）文件是由Aldus和Microsoft公司为扫描仪和桌上出版系统研制开发的一种较为通用的图像文件格式。TIFF格式灵活易变，它又定义了四类不同的格式：TIFF－B适用于二值图像；TIFF－G适用于黑白灰度图像；TIFF－P适用于带调色板的彩色图像；TIFF－R适用于RGB真彩图像。TIFF支持多种编码方法，其中包括RGB无压缩、RLE压缩及JPEG压缩等。

（四）GIF格式

GIF（Graphics Interchange Format ）是CompuServe公司在1987年开发的图像文件格式，1989年在1987年版本基础上进行了扩充，扩充后的版本号定义为GIF89a，而1987年版本则为GIF87a。GIF采用LZW压缩算法来存储图像数据，并采用了可变长度等压缩算法。GIF的图像深度从1 bit到8 bit，也即GIF最多支持256种颜色的图像。GIF格式的另一个特点是其在一个GIF文件中可以存多幅彩色图像，如果把存于一个文件中的多幅图像数据逐幅读出并显示到屏幕上，就可构成一种最简单的动画。

（五）SWF格式

SWF（Shock Wave Flash）是Macromedia公司软件Flash生成的一种动画文件格式。这是一种网络矢量图形标准，压缩率高，但需要Flash软件或插件才能播放。

（六）JPEG格式

JPEG（Joint Photographic Experts Group）是由CCITT（国际电报电话咨询委员会）和ISO（国际标准化组织）联合组成的一个图像专家组。该专家组制定的第一个压缩静态数字图像的国际标准，其标准名称为“连续色调静态图像的数字压缩和编码（Digital Compression and Coding of Continuous - tone Still Image）”，简称为JPEG算法。这是一个适用范围很广的通用标准，其目标如下：

1．开发的算法在图像压缩率方面是 / 或接近当前的科学水平，图像的保真度在较宽的压缩范围里的评价是“很好”、“优秀”到与原图像“不能区别”。

2．开发的算法可实际应用于任何一类数字图像源，如对图像的大小、颜色空间、像素的长宽比、图像的内容、复杂程度、颜色数及统计特性等都不加限制。

3．对开发的算法，在计算的复杂程度方面可以调整，因而可根据性能和成本要求选择用软件执行还是用硬件执行。

4．开发的算法包括顺序编码、累进编码、无损压缩编码和分层编码等4种编码方式。

JPEG采用对称的压缩算法，也即在同一系统环境下压缩和解压缩所用的时间相同。采用JPEG压缩编码算法压缩的图像，其压缩比约为1:5至1:50，甚至更高。从实例中可以看出不同压缩比及其压缩效果。

在一般的图像处理软件中，对一幅图像按JPEG格式进行压缩时，用户可以选择压缩质量因子（Quality Factor）。Photoshop图像软件按4大类质量，把压缩因子分为0—10等级；PhotoPaint 图像软件把质量因子量化为2~250等分。采用Photoshop定义的质量因子的效果示例见图06-05-4。

当采用JPEG的高质量压缩时，未受训练的人眼无法查觉到变化。在低质量压缩率下，大部分的数据被剔除，而眼睛对之敏感的信息内容则几乎全部保留下来。

从效果图06-05-4（1）和（2）中可以进一步说明的是，相同的压缩因子用于不同的图像时得到的压缩比和压缩效果可能不完全相同，这与原图的复杂程度、色块分布有很大关系。因此，实际应用时需根据要求及实际效果而选定压缩因子。

　　要利用计算机对数字化图像进行处理，首先要对图像的文件格式要有清楚的认识，因为我们前面说过，自然界的图像以模拟信号的形式存在，在用计算机进行处理以前，首先要数字化，比如摄像头（CCD）摄取的信号在送往计算机处理前，一般情况下要经过数模转换，这个任务常常由图像采集卡完成，它的输出一般为裸图的形式；如果用户想要生成目标图像文件，必须根据文件的格式做相应的处理。随着科技的发展，数码像机、数码摄像机已经进入寻常百姓家，我们可以利用这些设备作为图像处理系统的输入设备来为后续的图像处理提供信息源。无论是什么设备，它总是提供按一定的图像文件格式来提供信息，比较常用的有BMP格式、JPEG格式、GIF格式等等，所以我们在进行图像处理以前，首先要对图像的格式要有清晰的认识，只有在此基础上才可以进行进一步的开发处理。

牋牋在讲述图像文件格式前，先对图像作一个简单的分类。除了最简单的图像外，所有的图像都有颜色，而单色图像则是带有颜色的图像中比较简单的格式，它一般由黑色区域和白色区域组成，可以用一个比特表示一个像素，“1”表示黑色，“0”表示白色，当然也可以倒过来表示，这种图像称之为二值图像。我们也可以用8个比特（一个字节）表示一个像素，相当于把黑和白等分为256个级别，“0”表示为黑，“255”表示为白，该字节的数值表示相应像素值的灰度值或亮度值，数值越接近“0”，对应像素点越黑，相反，则对应像素点越白，此种图像我们一般称之为灰度图像。单色图像和灰度图像又统称为黑白图像，与之对应存在着彩色图像，这种图像要复杂一些，表示图像时，常用的图像彩色模式有RGB模式、CMYK模式和HIS模式，一般情况下我们只使用RGB模式，R对应红色，G对应绿色，B对应蓝色，它们统称为三基色，这三中色彩的不同搭配，就可以搭配成各种现实中的色彩，此时彩色图像的每一个像素都需要3个样本组成的一组数据表示，其中每个样本用于表示该像素的一个基本颜色。

　　对于现存的所有的图像文件格式，我们在这里主要介绍BMP图像文件格式，并且文件里的图像数据是未压缩的，因为图像的数字化处理主要是对图像中的各个像素进行相应的处理，而未压缩的BMP图像中的像素数值正好与实际要处理的数字图像相对应，这种格式的文件最合适我们对之进行数字化处理。请读者记住，压缩过的图像是无法直接进行数字化处理的，如JPEG、GIF等格式的文件，此时首先要对图像文件解压缩，这就要涉及到一些比较复杂的压缩算法。后续章节中我们将针对特殊的文件格式如何转换为BMP格式的文件问题作专门的论述，经过转换，我们就可以利用得到的未压缩的BMP文件格式进行后续处理。对于JPEG、GIF等格式，由于涉及到压缩算法，这要求读者掌握一定的信息论方面的知识，如果展开的话，可以写一本书，限于篇幅原因，我们只作一般性的讲解，有兴趣的朋友可以参考相关书籍资料。

一、BMP文件结构

　　1. BMP文件组成

　　 BMP文件由文件头、位图信息头、颜色信息和图形数据四部分组成。文件头主要包含文件的大小、文件类型、图像数据偏离文件头的长度等信息；位图信息头包含图象的尺寸信息、图像用几个比特数值来表示一个像素、图像是否压缩、图像所用的颜色数等信息。颜色信息包含图像所用到的颜色表，显示图像时需用到这个颜色表来生成调色板，但如果图像为真彩色，既图像的每个像素用24个比特来表示，文件中就没有这一块信息，也就不需要操作调色板。文件中的数据块表示图像的相应的像素值，需要注意的是：图像的像素值在文件中的存放顺序为从左到右，从下到上，也就是说，在BMP文件中首先存放的是图像的最后一行像素，最后才存储图像的第一行像素，但对与同一行的像素，则是按照先左边后右边的的顺序存储的；另外一个需要读者朋友关注的细节是：文件存储图像的每一行像素值时，如果存储该行像素值所占的字节数为4的倍数，则正常存储，否则，需要在后端补0，凑足4的倍数。

　　 2. BMP文件头

　　 BMP文件头数据结构含有BMP文件的类型、文件大小和位图起始位置等信息。其结构定义如下:

typedef struct tagBITMAPFILEHEADER

{

WORD bfType; // 位图文件的类型，必须为“BM”

DWORD bfSize; // 位图文件的大小，以字节为单位

WORD bfReserved1; // 位图文件保留字，必须为0

WORD bfReserved2; // 位图文件保留字，必须为0

DWORD bfOffBits; // 位图数据的起始位置，以相对于位图文件头的偏移量表示，以字节为单位

} BITMAPFILEHEADER；该结构占据14个字节。

　　3. 位图信息头

　　BMP位图信息头数据用于说明位图的尺寸等信息。其结构如下：

typedef struct tagBITMAPINFOHEADER{

DWORD biSize; // 本结构所占用字节数

LONG biWidth; // 位图的宽度，以像素为单位

LONG biHeight; // 位图的高度，以像素为单位

WORD biPlanes; // 目标设备的平面数不清，必须为1

WORD biBitCount// 每个像素所需的位数，必须是1(双色), 4(16色)，8(256色)或24(真彩色)之一

DWORD biCompression; // 位图压缩类型，必须是 0(不压缩),1(BI_RLE8压缩类型)或2(BI_RLE4压缩类型)之一

DWORD biSizeImage; // 位图的大小，以字节为单位

LONG biXPelsPerMeter; // 位图水平分辨率，每米像素数

LONG biYPelsPerMeter; // 位图垂直分辨率，每米像素数

DWORD biClrUsed;// 位图实际使用的颜色表中的颜色数

DWORD biClrImportant;// 位图显示过程中重要的颜色数

} BITMAPINFOHEADER；该结构占据40个字节。

　　注意：对于BMP文件格式，在处理单色图像和真彩色图像的时候，无论图象数据多么庞大，都不对图象数据进行任何压缩处理，一般情况下，如果位图采用压缩格式，那么16色图像采用RLE4压缩算法，256色图像采用RLE8压缩算法。

　　4. 颜色表

　　颜色表用于说明位图中的颜色，它有若干个表项，每一个表项是一个RGBQUAD类型的结构，定义一种颜色。RGBQUAD结构的定义如下:

typedef struct tagRGBQUAD {

BYTErgbBlue;// 蓝色的亮度(值范围为0-255)

BYTErgbGreen; // 绿色的亮度(值范围为0-255)

BYTErgbRed; // 红色的亮度(值范围为0-255)

BYTErgbReserved;// 保留，必须为0

} RGBQUAD;

　　颜色表中RGBQUAD结构数据的个数由BITMAPINFOHEADER 中的biBitCount项来确定，当biBitCount=1,4,8时，分别有2,16,256个颜色表项，当biBitCount=24时，图像为真彩色，图像中每个像素的颜色用三个字节表示，分别对应R、G、B值，图像文件没有颜色表项。位图信息头和颜色表组成位图信息，BITMAPINFO结构定义如下:

typedef struct tagBITMAPINFO {

BITMAPINFOHEADER bmiHeader; // 位图信息头

RGBQUAD bmiColors[1]; // 颜色表

} BITMAPINFO;

　　注意：RGBQUAD数据结构中，增加了一个保留字段rgbReserved，它不代表任何颜色，必须取固定的值为“0”，同时，RGBQUAD结构中定义的颜色值中，红色、绿色和蓝色的排列顺序与一般真彩色图像文件的颜色数据排列顺序恰好相反，既：若某个位图中的一个像素点的颜色的描述为“00，00，ff，00”，则表示该点为红色，而不是蓝色。

　　5. 位图数据

　　位图数据记录了位图的每一个像素值或该对应像素的颜色表的索引值，图像记录顺序是在扫描行内是从左到右,扫描行之间是从下到上。这种格式我们又称为Bottom_Up位图，当然与之相对的还有Up_Down形式的位图，它的记录顺序是从上到下的，对于这种形式的位图，也不存在压缩形式。位图的一个像素值所占的字节数：当biBitCount=1时，8个像素占1个字节；当biBitCount=4时，2个像素占1个字节；当biBitCount=8时，1个像素占1个字节；当biBitCount=24时,1个像素占3个字节，此时图像为真彩色图像。当图像不是为真彩色时，图像文件中包含颜色表，位图的数据表示对应像素点在颜色表中相应的索引值，当为真彩色时，每一个像素用三个字节表示图像相应像素点彩色值，每个字节分别对应R、G、B分量的值，这时候图像文件中没有颜色表。上面我已经讲过了，Windows规定图像文件中一个扫描行所占的字节数必须是4的倍数(即以字为单位),不足的以0填充，图像文件中一个扫描行所占的字节数计算方法：

DataSizePerLine= (biWidth* biBitCount+31)/8；// 一个扫描行所占的字节数

　　位图数据的大小按下式计算(不压缩情况下)：

　　DataSize= DataSizePerLine* biHeight。

　　上述是BMP文件格式的说明，搞清楚了以上的结构，就可以正确的操作图像文件，对它进行读或写操作了。

二、GIF图像文件格式

　　GIF图象格式的全称为Graphics Interchange Format，从这个名字可以看出，这种图像格式主要是为了通过网络传输图像而设计的。GIF文件不支持24位真彩色图像，最多只能存储256色的图像或灰度图像；GIF格式文件也无法存储CMY和HIS模型的图像数据；另外，GIF图像文件的各种数据区域一般没有固定的数据长度和存储顺序，所以为了方便程序寻找数据区，将数据区中的第一个字节作为标志符；最后需要读者注意的是GIF文件存储图像数据是有二种排列顺序：顺序排列或交叉排列。交叉排列的方式适合网络传输，这样一来允许用户在不完全掌握图像数据之前，获取当前图像的轮廓数据。

　　 GIF文件格式分为87和89两个版本，对于87这个版本，该文件主要是有五个部分组成，它，们是按顺序出现的：文件头块、逻辑屏幕描述块、可选择的调色板块、图像数据块、最后是标志文件结束的尾块，该块总是取固定的值3BH。其中第一和第二两个块用GIF图像文件头结构描述：

GIFHEADER：{

DB Signature; //该字段占六个字节，为了用于指明图像为GIF格式，前三个字符必须为“GIF”，后三字符用于指定是哪个版本，87或89。

DW ScreenWidth;//

DW ScreenDepth;//占两个字节，以像素为单位表示图像的宽、高

DB GlobalFlagByte;//该字节的各个位用于调色版的描述

DB BackGroundColor;//代表图象的背景颜色的索引

DB AspectRatio;图像的长宽比

}

　　GIF格式中的调色板有通用调色板和局部调色板之分，因为GIF格式允许一个文件中存储多个图像，因此有这两种调色板，其中通用调色板适于文件中的所有图像，而局部调色板只适用于某一个图像。格式中的数据区域一般分为四个部分，图像数据识别区域，局部调色板数据，采用压缩算法得到的图象数据区域和结束标志区域。

　　在GIF89版本中，它包含七个部分，分别是文件头、通用调色板数据、图像数据区和四个补充数据区，它们主要是用于提示程序如何处理图像的。

BMP位图包括位图文件头结构BITMAPFILEHEADER、位图信息头结构BITMAPINFOHEADER、位图颜色表RGBQUAD和位图像素数据四部分。处理位图时要根据文件的这些结构得到位图文件大小、位图的宽、高、实现调色板、得到位图像素值等等。这里要注意的一点是在BMP位图中，位图的每行像素值要填充到一个四字节边界，即位图每行所占的存储长度为四字节的倍数，不足时将多余位用0填充。

　　有了上述知识，可以开始编写图像处理的程序了，关于在VC的开发平台上如何开发程序的问题这里不再赘述，笔者假定读者都具有一定的VC开发经验。在开发该图像处理程序的过程中，笔者没有采用面向对象的方法，虽然面向对象的方法可以将数据封装起来，保护类中的数据不受外界的干扰，提高数据的安全性，但是这种安全性是以降低程序的执行效率为代价的，为此，我们充分利用了程序的文档视图结构，在程序中直接使用了一些API函数来操作图像。在微软的MSDN中有一个名为Diblook的例子，该例子演示了如何操作Dib位图，有兴趣的读者可以参考一下，相信一定会有所收获。

　　 启动Visual C++，生成一个名为Dib的多文档程序，将CDibView类的基类设为CscrollView类，这样作的目的是为了在显示位图时支持滚动条，另外在处理图像应用程序的文档类（CDibDoc.h）中声明如下宏及公有变量：

#define WIDTHBYTES(bits) (((bits) + 31) / 32 * 4)//计算图像每行象素所占的字节数目；

HANDLE m_hDIB;//存放位图数据的句柄；

CPalette* m_palDIB;//指向调色板Cpalette类的指针；

CSize m_sizeDoc;//初始化视图的尺寸，该尺寸为位图的尺寸；

　　最后将程序的字符串表中的字符串资源IDR_DibTYPE修改为：“\nDib\nDib\nDib Files(*.bmp;*.dib)\n.bmp\nDib.Document\nDib Document”。这样作的目的是为了在程序文件对话框中可以选择BMP或DIB格式的位图文件。

　　1、 读取灰度BMP位图

　　可以根据BMP位图文件的结构，操作BMP位图文件并读入图像数据，为此我们充分利用了VC的文档视图结构，重载了文挡类的OnOpenDocument（）函数，这样用户就可以在自动生成程序的打开文件对话框中选择所要打开的位图文件，然后程序将自动调用该函数执行读取数据的操作。该函数的实现代码如下所示：

BOOL CDibDoc::OnOpenDocument(LPCTSTR lpszPathName)

{

LOGPALETTE *pPal;//定义逻辑调色板指针；

pPal=new LOGPALETTE;//初始化该指针；

CFile file;

CFileException fe;

if (!file.Open(lpszPathName, CFile::modeRead | CFile::shareDenyWrite, &fe))

{//以“读”的方式打开文件；

AfxMessageBox("图像文件打不开！");

return FALSE;

}

DeleteContents();//删除文挡；

BeginWaitCursor();

BITMAPFILEHEADER bmfHeader;//定义位图文件头结构；

LPBITMAPINFO lpbmi;

DWORD dwBitsSize;

HANDLE hDIB;

LPSTR pDIB;//指向位图数据的指针；

BITMAPINFOHEADER *bmhdr;//指向位图信息头结构的指针

dwBitsSize = file.GetLength();//得到文件长度

if (file.Read((LPSTR)&bmfHeader, sizeof(bmfHeader)) !=sizeof(bmfHeader))

return FALSE;//读取位图文件的文件头结构信息；

if (bmfHeader.bfType != 0x4d42) //检查该文件是否为BMP格式的文件；

return FALSE;

hDIB=(HANDLE) ::GlobalAlloc(GMEM_MOVEABLE | GMEM_ZEROINIT, dwBitsSize);

//为读取图像文件数据申请缓冲区

if (hDIB == 0)

{

return FALSE;

}

pDIB = (LPSTR) ::GlobalLock((HGLOBAL)hDIB);

//得到申请的缓冲区的指针；

if (file.ReadHuge(pDIB, dwBitsSize - sizeof(BITMAPFILEHEADER)) !=

dwBitsSize - sizeof(BITMAPFILEHEADER) )

{

::GlobalUnlock((HGLOBAL)hDIB);

hDIB=NULL;

return FALSE;

}//此时pDIB数据块中读取的数据包括位图头信息、位图颜色表、图像像素的灰度值；

bmhdr=(BITMAPINFOHEADER*)pDIB;//为指向位图信息头结构的指针赋值；

::GlobalUnlock((HGLOBAL)hDIB);

if ((*bmhdr).biBitCount!=8)//验证是否为8bit位图

{

AfxMessageBox("该文件不是灰度位图格式！");

return FALSE;

}

m_hDIB=hDIB;//将内部变量数据赋于全局变量；

//下面是记录位图的尺寸；

m_sizeDoc.x=bmhdr->biWidth;

m_sizeDoc.y=bmhdr->biHeight;

//下面是根据颜色表生成调色板；

m_palDIB=new Cpalette;

pPal->palVersion=0x300;//填充逻辑颜色表

pPal->palNumEntries=256;

lpbmi=(LPBITMAPINFO)bmhdr;

for(int i=0;i<256;i++)

{//每个颜色表项的R、G、B值相等，并且各个值从“0”到“255”序列展开；

Pal->palPalentry[i].peRed=lpbmi->bmiColors[i].rgbRed;

pPal->palPalentry[i].peGreen=lpbmi->bmiColors[i].rgbGreen;

pPal->palPalentry[i].peBlue= lpbmi->bmiColors[i].rgbBlue;;

pPal->palPalentry[i].peFlags=0;

}

m_palDIB->CreatePalette(pPal);

//根据读入的数据得到位图的宽、高、颜色表;

if(pPal)

delete pPal;

EndWaitCursor();

SetPathName(lpszPathName);//设置存储路径

SetModifiedFlag(FALSE); // 设置文件修改标志为FALSE

return TRUE;

}

　　上面的方法是通过CFile类对象的操作来读取位图文件的，它需要分析位图中的文件头信息，从而确定需要读取的图像长度。这种方法相对来说有些繁琐，其实还可以以一种相对简单的方法读取位图数据，首先在程序的资源中定义DIB类型资源，然后添加位图到该类型中，将图像数据以资源的形式读取出来，这时候就可以根据所获取的数据中的位图信息结构来获取、显示图像数据了。下面的函数实现了以资源形式装载图像文件数据，该函数的实现代码如下所示：

/////////////////////////////////////////////////////////////////

HANDLE LoadDIB(UINT uIDS, LPCSTR lpszDibType)

{

LPCSTR lpszDibRes =MAKEINTRESOURCE(uIDS);//根据资源标志符确定资源的名字；

HINSTANCE hInst=AfxGetInstanceHandle();//得到应用程序的句柄；

HRSRC hRes=：：FindResource(hInst,lpszDibRes, lpszDibType);//获取资源的句柄，这里lpszDibType为资源的名字“DIB”;

If(hRes==NULL)

return NULL

HGLOBAL hData=：：LoadResource(hInst, hRes);//转载资源数据并返回该句柄；

return hData;

}

　　2、 灰度位图数据的存储

　　为了将图像处理后所得到的像素值保存起来，我们重载了文档类的OnSaveDocument（）函数，这样用户在点击Save或SaveAs子菜单后程序自动调用该函数，实现图像数据的存储。该函数的具体实现如下：

///////////////////////////////////////////////////////////////////

BOOL CDibDoc::OnSaveDocument(LPCTSTR lpszPathName)

{

CFile file;

CFileException fe;

BITMAPFILEHEADER bmfHdr; // 位图文件头结构；

LPBITMAPINFOHEADER lpBI;//指向位图头信息结构的指针；

DWORD dwDIBSize;；

if (!file.Open(lpszPathName, CFile::modeCreate |CFile::modeReadWrite | CFile::shareExclusive, &fe))

{

AfxMessageBox("文件打不开")；

return FALSE;

}//以读写的方式打开文件；

BOOL bSuccess = FALSE;

BeginWaitCursor();

lpBI = (LPBITMAPINFOHEADER) ::GlobalLock((HGLOBAL) m_hDIB);

if (lpBI == NULL)

return FALSE;

dwDIBSize = *(LPDWORD)lpBI + 256*sizeof(RGBQUAD);

//图像的文件信息所占用的字节数；

DWORD dwBmBitsSize;//BMP文件中位图的像素所占的字节数

dwBmBitsSize=WIDTHBYTES((lpBI->biWidth)*((DWORD)lpBI->biBitCount))

*lpBI->biHeight;// 存储时位图所有像素所占的总字节数

dwDIBSize += dwBmBitsSize; //BMP文件除文件信息结构外的所有数据占用的总字节数；

lpBI->biSizeImage = dwBmBitsSize; // 位图所有像素所占的总字节数

//以下五句为文件头结构填充值

bmfHdr.bfType =0x4d42; // 文件为"BMP"类型

bmfHdr.bfSize = dwDIBSize + sizeof(BITMAPFILEHEADER);//文件总长度

bmfHdr.bfReserved1 = 0;

bmfHdr.bfReserved2 = 0;

bmfHdr.bfOffBits = (DWORD)sizeof(BITMAPFILEHEADER) + lpBI->biSize

+ 256*sizeof(RGBQUAD);

//位图数据距离文件头的偏移量；

file.Write((LPSTR)&bmfHdr, sizeof(BITMAPFILEHEADER));//向文件中写文件头信息；

file.WriteHuge(lpBI, dwDIBSize);

//将位图信息（信息头结构、颜色表、像素数据）写入文件；

::GlobalUnlock((HGLOBAL) m_hDIB);

EndWaitCursor()；

SetModifiedFlag(FALSE)； // 将文档设为“干净”标志，表示此后文档不需要存盘提示；

return TRUE；

}