|
|
Anyway, this document was reproduced with permission, and we like to keep it that way, so I'd better stop dissing it.
This document based on materials found in the Drew Barrymore Logo Changer by XCDM Software V1.29.a6 (external alpha)
######## TECHNICAL NOTES FOR GENERATING MICROSOFT WINDOWS 95/98 LOGO'S########
This document is primarily designed to assist people who want to create their own custom logos, and is divided into 4 sections.
1) Format of a logo
2) Notes on resampling and 8 bit images
3) Format of an animated logo
4) .BMP general format specification
#### Format of a logo ####
All the logos supported by Windows must be 320 pixels wide, 400 pixels high, have a bit depth of 8 (256 colours) and conform to the Windows DIB/BMP format. Note these files can't be RLE compressed, and can't contain less than 256 palette entries. Information about the BMP 3 format is available in section 4, titled ".BMP general format specification". Such files are usually 129,078 bytes long (126K) but may vary in size by about 50 bytes depending on the program used to create them. Windows can handle varying file sizes, as long as the format is correct.
Note the aspect ratio of 4:5 (320:400) that this image has, compared to the aspect ratio of a full screen 4:3 (640:480). When windows displays the logo it changes the video mode to 320*400, in effect this *stretches* the 4:5 image into a 4:3 window. Because of this, for the image to look normal when displayed, the logo you create has to be squashed horizontally from a 4:3 image to a 4:5 image.
What does all that mean in reality? Create a 533*400 logo and resize/resample it to 320*400, and when windows displays it, it will look normal. If you make a 320*400 image that looks normal, it will appear stretched when windows displays it. If that sounds all to stupid then blame Micro$oft, not me, I had nothing to do with it, that's the way it is and we just have to deal with it.
The main reason why this format was employed is because 320*400*8 is the highest resolution 256 colour mode supported by all VGA video cards. And as the logo is displayed without using the windows video driver and windows 95 was designed to technically support a 386, (which are the machines most likely to make users grow impatient without an animated logo) The logo screens needed to work on the lowestcommon denominator.
#### Notes on resampling and 8 bit images ####
This information is provided to ensure you get the best quality logos given the "lossy" effect converting from 533*400*16M to 320*400*256 can produce. If you have already done a lot of image processing before, then the "rules" part of this section probably contains no new information; you should skip to the "more ideas" part.
RULE 1: Convert your 533*400*16M image to 256 colours first.
There is no point in doing all that photo editing work if the picture will just look bad as a 256 colour picture in the end anyway. Convert it to 256 colours and see how it looks. In general images with more than 50,000 distinct colours will not convert to 256 colours very well. If your image has too many colours try deleting some of the background, or forcing all the very dark colours to black, and all the very light colours to white. Read the "more ideas" part at the end of this section and see if any of it applies to your image. If it still looks bad after the conversion, then find another file to work on. If it looks fine as a 256 then re-open the original (16M colours) and start editing that, don't keep working with the 256.
RULE 2: Keep all your work in 16M colours (24 bit) for as long as possible.
Most of the images you will get from the internet will be 16M colour JPEG images anyway, but if they aren't, convert them to 16M colours before working with them. Convert your image to 256 colours as your final step.
RULE 3: When converting to 256 colours an "optimised" palette with "error diffusion"
Any good image editing program gives you options about the method by which the colour reduction process will occur. Use an optimised palate not a standard palate. If more than one optimised palate is available then experiment and see what turns out the best. Usually an "octree/perceptual" style optimised palate offers the best output. Never include the standard windows colours. It can sometimes be useful to play with weighted palates and colour boosting, but the results of doing this vary from image to image and program to program.
Use "error diffusion" over "nearest colour" or "pattern matching"/"dither". Enable "reduced colour bleeding" or use 40-80% diffusion when available.
RULE 4: Keep all your work in 533*400 until editing is complete.
Any cutting and pasting you do to the image when it is a 320*400 will be stretched when the image is displayed. Any arithmetic or deformation functions performed at this resolution may also result in loss of colour information.
RULE 5: Use bilinear resampling to convert from 533*400 to 320*400
Most image editors will do this by default, but if you are presented with the option, choose this method over "bicubic sampling" or "direct pixel resize"
RULE 6: Save intermediate steps as .BMP not .JPG.
You may want to save some of your intermediate steps in the image processing, so you can reload them if you make a mistake. If you do this, do not save your intermediate images as .JPG, use .BMP instead. Repeated encoding to the .JPG format progressively decreases picture quality.
RULE 7: Save your final work as an UNCOMPRESSED WINDOWS BMP
Check the save file preferences dialog box to ensure that your file is being saved as a Windows BMP not an OS/2 BMP and that it is stored uncompressed not in RLE mode. Both OS/2 Bitmaps and Windows RLE Bitmaps are not valid logos. If you can't find a save file preferences dialog box, it may be that your program doesn't have one, in which case it will save uncompressed windows BMP's by default.
MORE IDEAS:-
WORDS IN IMAGES:
If you want to use words on a single colour background as part of your image you should go about this differently from just producing a regular logo. The problem is that when you resample your 533*400 to 320*400; so that the words will retain their shape, many shades of the word and background will be created around the words. You don't want this, because the backround is not important, and all these new colours will mean there is less space for the important colours.
One way to get around this is to make two images. One contains the foreground picture, and the other contains the backround and words. Keep the foreground picture in 16M colours and resize it to 320*400. Resize the backround picture using "direct pixel resize" or (if you don't have that option) convert the backround image to 256 colours, resize then convert it back to 16M colours. Paste the important parts of the foreground image onto the backround image where they belong and then convert it all to 256 colours.
CREATE YOUR OWN PALLATE:
Sometimes even when you follow all the rules your image turns out bad in the end. Normally I'd suggest you just try a different image, but if you REALY love this one picture and want to use it anyway here's what to do.
* Open the truecolour image that doesn't convert to 256 colours well.
* Create a duplicate
* Convert the duplicate to 256 colours the best way you can
* Save its palate to a text file
* Open the text file
* If your image has a background that is a solid colour make sure this
colour
has not changed in the colour conversion. If it has then edit
that palate
entry in the text file so that that entry has the same colour
as the
original (truecolour) image
* Open up the colour picker for your 256 colour copy, you should see
the 256
colours your image editor chose for your image. Many of these
colours will
look practicly the same. About 40 will be almost black, 30 will
be almost
white. If there's grass in the backround another 30 will be
green, if you
haven't done anything to the backround or the forground is complex
there may
be upto 50 shades of the background colour as well. You don't
care about any
of these colours. For your image to look good you must emphasize
the skin,
hair, lip and eye colours.
* Decide which colours aren't important and write these down. Don't
go
overboard, you can always cut back some more later if you need
to. You
should add all dark colours that look exactly black, and about
half of those
that are very close, adding more than this will make shaddows
and hair look
bad. Don't add many whites to your list, I usually exclude pure
white and
two colours close to it, and then include only six colours close
to the
other two. If there's grass 10 shades of green is plenty, so
add all the
rest to your list. If there's many shades of your background
colour you can
slash and burn almost all of them.
* Count how many colours there are on your list
* Switch to your truecolour image and start taking down RGB colour
numbers
from areas in the face, especially the skin colours, until you
have enough
to replace all the colours on your list.
* Switch to the pallate text file and replace all the colours on your
list
for the ones you just got from the truecolour image.
* Save the palate text file.
* Switch to your truecolour image and load the palate you just saved
using
error diffusion.
This has just converted your truecolour image to 256 colours using a
palate
rich in the skin colours that existed in the original image. If you
do it
right this will always improve your 256 colour images.
SCANNED / JPEG DEGRADED IMAGES:
If you own a scanner then it's probably no news to you that images scanned from magazines turn out speckled and dithered. Most people have their own special way of working around this problem, and which is the best method depends alot on the scanner, software, scan matterial, dye method and personal taste. Most methods do involve some resizing, bluring, softening or sharpening. Be warned that whilst "despeckling" your scanned image will make it look better in truecolour, doing so usually drasticly increases the number of colours in the image. Try a few different methods to improve the scanned image quality and convert them all to 256 colours before deciding which is the best. Re-open your 16M, don't keep working with the 256.
#### Format of an animated logo ####
Animated logos aren't hard to understand, but they are hard if not impossible to create unless you have the right tools. Before you consider creating animated logos you should have
1) A HexEditor, capable of working in insert AND overtype modes.
2) A paint program capable of converting images to a non-standard number
of
colours (eg reduce a 16M colour image to 236 or
238 colours)
3) A paint program capable of saving and restoring palates as text.
If you don't have all three of these then you can still make startup logos, but you won't be able to make them animate. If this is the case then this section is not relevant to you.
As the section ".BMP general format specification" explains, a 256 colour BMP consists of a 256 entry colour table and an image containing the indexes of the colour table which contain the colour to paint at that location.
So in reality the image part of a BMP consists of thousands of numbers between 0 and 255. In an animated logo all the colours between 0 and biClrImportant can be found by looking up the colour values directly from the colour table. But the colours between biClrImportant and 255 must be found by looking up the colour table at position: (index - biClrImportant + n) MOD (256 - biClrImportant) + biClrImportant where n is an integer that starts at 0 and increases as windows loads
Here's an example. The default windows startup logo uses 236 fixed colours and 20 "animatable" colours. The biClrImportant field in the BMP is set to 236 (0xEC)
Original file index(n=0) New file index(n=1)
New file index(n=2)
0 0 0
1 1 1
.
.
.
235 235 235
236 237 238
237 238 239
.
.
.
254 255 236
255 236 237
The effect Micro$oft has created is that of a gradual transition from blue to white and back again. The placement of the different shades of blue and white in the logo makes it appear as though the image is moving, where in reality it isn't.
The value of the biClrImportant field can be set from 0 (all pixels animate) To 255 (no pixels animate). 255 is the setting used by all image editors I've used, so the only way to change it is with a "HexEditor". The one I recommend is Breakpoint Software's "Hex Workshop".
It is imperative that you ensure that pixels you do not want to change colour have indicies less than biClrImportant. If you do not do this then parts of the main picture will animate, and this looks UGLY. The best way to ensure this is to convert your image to the same number of colours as biClrImportant NOT just 256. This will require a program like PaintShopPro or PhotoShopDeluxe which can convert images to "X colours -8bit". Use the same rules when converting to X colours as converting to 256 colours to achieve best results.
By now you should realise there is a trade off between main picture quality and animation level, considering both must occupy different, continuous colour space within a fixed 256 index table.
You must now define the colours above biClrImportant and draw the animated part using these colours. How you go about this will depend very much on the paint program you are using, the project you are creating and your imagination.
And finally to something hardware related. Earlier I said 320*400*8 is supported by all VGA cards. Due to ram metrics, modern video cards will usually put a less than five pixel wide border around your image without you asking. the colour of this border is the same as the first colour in your palette. So unless you want a bright green border, make the first palette colour close to black, and nobody will even notice the border.
This will probably seem a lot clearer to you if you read this next section. If not then don't worry, being able to examine the guts of a .BMP file is not a criteria for 99.99% of jobs I can think of. Non-animating logos are OK to use as startup screens.
#### .BMP general format specification ####
This information is taken directly from PCGPE Version 1 which claims it got it off Usenet, so considering it's freely available off the Usenet anyway there should be no legal problem with it appearing here. If there is then don't bother telling me 'cos I'll probably just think you're fooling with me anyway.
I haven't changed any of it, and it seems to be accurate, but if there's
an obvious mistake somewhere then tell me, and I'll fix it up for next
time. To be honest though I think everybody stopped reading this document
3 pages ago.
------------------------------------------------------------------------------
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
.
==============================================================================
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
rgbtBlue Specifies 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
-----------------------------------------------------------------------------
You haven't fallen asleep yet! What's wrong with you?