哪里能找到BMP格式的中文资料

ybsh 2001-12-05 12:45:15
...全文
135 2 打赏 收藏 转发到动态 举报
写回复
用AI写文章
2 条回复
切换为时间正序
请发表友善的回复…
发表回复
Colorstone0823 2001-12-05
  • 打赏
  • 举报
回复
bmp format

table of contents

introduction
bitmap file format
general
bmp contents
field details
height field
bits per pixel field
compression field
colors field
important colors field

introduction

this document describes the microsoft windows and ibm os/2 picture bitmap files, called bitmaps or bmp files. most of the descriptions of the bmp file concentrate on the microsoft windows bmp structures like bmpinfoheader and bmpcoreinfo , but only a few describe the file contents on byte level. this information is therefor only intended to be used in applications where direct reading and writing of a bmp file is required.

bitmap file format

the following chapters contain the detailed information on the contents of the bmp file. first more general information will be given regarding the byte order and file alignment. the second chapter will concentrate on the byte-level contents of a bmp file. the third chapter will elaborate on this chapter and explain some of the concepts - like compression - and/or values in detail.

general

the bmp file has been created by microsoft and ibm and is therefor very strictly bound to the architecture of the main hardware platform that both companies support: the ibm compatible pc. this means that all values stored in the bmp file are in the intel format, sometimes also called the little endian format because of the byte order that an intel processor uses internally to store values.

the bmp files are the way, windows stores bit mapped images. the bmp image data is bit packed but every line must end on a dword boundary - if that抯 not the case, it must be padded with zeroes. bmp files are stored bottom-up, that means that the first scan line is the bottom line.

the bmp format has four incarnations, two under windows (new and old) and two under os/2, all are described here.

bmp contents

the following table contains a description of the contents of the bmp file. for every field, the file offset, the length and the contents will be given. for a more detailed discussion, see the following chapters.

offset
field
size
contents

0000h
identifier
2 bytes
the characters identifying the bitmap. the following entries are possible:

態m’ - windows 3.1x, 95, nt, …

態a’ - os/2 bitmap array

慍i’ - os/2 color icon

慍p’ - os/2 color pointer

慖c’ - os/2 icon

慞t’ - os/2 pointer

0002h
file size
1 dword
complete file size in bytes.

0006h
reserved
1 dword
reserved for later use.

000ah
bitmap data offset
1 dword
offset from beginning of file to the beginning of the bitmap data.

000eh
bitmap header size
1 dword
length of the bitmap info header used to describe the bitmap colors, compression, … the following sizes are possible:

28h - windows 3.1x, 95, nt, …

0ch - os/2 1.x

f0h - os/2 2.x

0012h
width
1 dword
horizontal width of bitmap in pixels.

0016h
height
1 dword
vertical height of bitmap in pixels.

001ah
planes
1 word
number of planes in this bitmap.

001ch
bits per pixel
1 word
bits per pixel used to store palette entry information. this also identifies in an indirect way the number of possible colors. possible values are:

1 - monochrome bitmap

4 - 16 color bitmap

8 - 256 color bitmap

16 - 16bit (high color) bitmap

24 - 24bit (true color) bitmap

32 - 32bit (true color) bitmap

001eh
compression
1 dword
compression specifications. the following values are possible:

0 - none (also identified by bi_rgb)

1 - rle 8-bit / pixel (also identified by bi_rle4)

2 - rle 4-bit / pixel (also identified by bi_rle8)

3 - bitfields (also identified by bi_bitfields)

0022h
bitmap data size
1 dword
size of the bitmap data in bytes. this number must be rounded to the next 4 byte boundary.

0026h
hresolution
1 dword
horizontal resolution expressed in pixel per meter.

002ah
vresolution
1 dword
vertical resolution expressed in pixels per meter.

002eh
colors
1 dword
number of colors used by this bitmap. for a 8-bit / pixel bitmap this will be 100h or 256.

0032h
important colors
1 dword
number of important colors. this number will be equal to the number of colors when every color is important.

0036h
palette
n * 4 byte
the palette specification. for every entry in the palette four bytes are used to describe the rgb values of the color in the following way:

1 byte for blue component

1 byte for green component

1 byte for red component

1 byte filler which is set to 0 (zero)

0436h
bitmap data
x bytes
depending on the compression specifications, this field contains all the bitmap data bytes which represent indices in the color palette.


 

note: the following sizes were used in the specification above:

size
# bytes
sign

char
1
signed

word
2
unsigned

dword
4
unsigned


field details

some of the fields require some more information. the following chapters will try to provide this information:

height field

the height field identifies the height of the bitmap in pixels. in other words, it describes the number of scan lines of the bitmap. if this field is negative, indicating a top-down dib, the compression field must be either bi_rgb or bi_bitfields. top-down dibs cannot be compressed.

bits per pixel field

the bits per pixel (bbp) field of the bitmap file determines the number of bits that define each pixel and the maximum number of colors in the bitmap.

when this field is equal to 1.
the bitmap is monochrome, and the palette 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 palette; if the bit is set, the pixel has the color of the second entry in the table.

 

when this field is equal to 4.
the bitmap has a maximum of 16 colors, and the palette contains up to 16 entries. each pixel in the bitmap is represented by a 4-bit index into the palette. for example, if the first byte in the bitmap is 1fh, the byte represents two pixels. the first pixel contains the color in the second palette entry, and the second pixel contains the color in the sixteenth palette entry.

 

when this field is equal to 8.
the bitmap has a maximum of 256 colors, and the palette contains up to 256 entries. in this case, each byte in the array represents a single pixel.

 

when this field is equal to 16.
the bitmap has a maximum of 2^16 colors. if the compression field of the bitmap file is set to bi_rgb, the palette field does not contain any entries. each word in the bitmap array represents a single pixel. the relative intensities of red, green, and blue are represented with 5 bits for each color component. the value for blue is in the least significant 5 bits, followed by 5 bits each for green and red, respectively. the most significant bit is not used.

if the compression field of the bitmap file is set to bi_bitfields, the palette field contains three dword color masks that specify the red, green, and blue components, respectively, of each pixel. each word in the bitmap array represents a single pixel.

windows nt specific: when the compression field is set to bi_bitfields, bits set in each dword mask must be contiguous and should not overlap the bits of another mask. all the bits in the pixel do not have to be used.

windows 95 specific: when the compression field is set to bi_bitfields, windows 95 supports only the following 16bpp color masks: a 5-5-5 16-bit image, where the blue mask is 0x001f, the green mask is 0x03e0, and the red mask is 0x7c00; and a 5-6-5 16-bit image, where the blue mask is 0x001f, the green mask is 0x07e0, and the red mask is 0xf800.

 

when this field is equal to 24.
the bitmap has a maximum of 2^24 colors, and the palette field does not contain any entries. each 3-byte triplet in the bitmap array represents the relative intensities of blue, green, and red, respectively, for a pixel.

 

when this field is equal to 32.
the bitmap has a maximum of 2^32 colors. if the compression field of the bitmap is set to bi_rgb, the palette field does not contain any entries. each dword in the bitmap array represents the relative intensities of blue, green, and red, respectively, for a pixel. the high byte in each dword is not used.

if the compression field of the bitmap is set to bi_bitfields, the palette field contains three dword color masks that specify the red, green, and blue components, respectively, of each pixel. each dword in the bitmap array represents a single pixel.

windows nt specific: when the compression field is set to bi_bitfields, bits set in each dword mask must be contiguous and should not overlap the bits of another mask. all the bits in the pixel do not have to be used.

windows 95 specific: when the compression field is set to bi_bitfields, windows 95 supports only the following 32bpp color mask: the blue mask is 0x000000ff, the green mask is 0x0000ff00, and the red mask is 0x00ff0000.

compression field

the compression field specifies the way the bitmap data is stored in the file. this information together with the bits per pixel (bpp) field identifies the compression algorithm to follow.

the following values are possible in this field:

value
meaning

bi_rgb
an uncompressed format.

bi_rle4
an rle format for bitmaps with 4 bits per pixel. the compression format is a two-byte format consisting of a count byte followed by two word-length color indices. for more information, see the following remarks section.

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

bi_bitfields
specifies that the bitmap is not compressed and that the color table consists of three double word color masks that specify the red, green, and blue components, respectively, of each pixel. this is valid when used with 16- and 32- bits-per-pixel bitmaps.


when the compression field is bi_rle8, the bitmap is compressed by using a run-length encoding (rle) format for an 8-bit bitmap. this format can be compressed in encoded or absolute modes. both modes can occur anywhere in the same 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 delta. the interpretation of the escape depends on the value of the second byte of the pair, which can be one of the following:

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.
the first byte is zero and the second byte is a value in the range 03h through ffh. 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 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

 

when the compression field is bi_rle4, the bitmap is compressed by using a run-length encoding 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 indices in the second byte. the second byte contains two color indices, one in its high-order four bits and one in its low-order four bits. the first of the pixels is drawn using the color specified by the high-order four bits, the second is drawn using the color in the low-order four bits, the third is drawn using the color in the high-order four bits, and so on, until all the pixels specified by the first byte have been drawn.

in absolute mode.
the first byte is zero, the second byte contains the number of color indices that follow, and subsequent bytes contain color indices in their high- and low-order four bits, 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 described for bi_rle8 also apply to bi_rle4 compression.

 

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

colors field

the colors field specifies the number of color indices in the color table that are actually used by the bitmap. if this value is zero, the bitmap uses the maximum number of colors corresponding to the value of the bbp field for the compression mode specified by the compression field.

if the colors field is nonzero and the bbp field less than 16, the colors field specifies the actual number of colors the graphics engine or device driver accesses.

if the bbp field is 16 or greater, then colors field specifies the size of the color table used to optimize performance of windows color palettes.

if bbp equals 16 or 32, the optimal color palette starts immediately following the three double word masks.

if the bitmap is a packed bitmap (a bitmap in which the bitmap array immediately follows the bitmap header and which is referenced by a single pointer), the colors field must be either 0 or the actual size of the color table.

important colors field

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


Colorstone0823 2001-12-05
  • 打赏
  • 举报
回复
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
.

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

16,551

社区成员

发帖
与我相关
我的任务
社区描述
VC/MFC相关问题讨论
社区管理员
  • 基础类社区
  • Creator Browser
  • encoderlee
加入社区
  • 近7日
  • 近30日
  • 至今
社区公告

        VC/MFC社区版块或许是CSDN最“古老”的版块了,记忆之中,与CSDN的年龄几乎差不多。随着时间的推移,MFC技术渐渐的偏离了开发主流,若干年之后的今天,当我们面对着微软的这个经典之笔,内心充满着敬意,那些曾经的记忆,可以说代表着二十年前曾经的辉煌……
        向经典致敬,或许是老一代程序员内心里面难以释怀的感受。互联网大行其道的今天,我们期待着MFC技术能够恢复其曾经的辉煌,或许这个期待会永远成为一种“梦想”,或许一切皆有可能……
        我们希望这个版块可以很好的适配Web时代,期待更好的互联网技术能够使得MFC技术框架得以重现活力,……

试试用AI创作助手写篇文章吧