Many people in the dump bmp file, there will be a variety of problems, especially when the screen capture, often preserved strange picture, large deviations! Such as the following:
Sometimes, obviously feeling that he is right, but the result is often drives people crazy.
This situation is generally bmp file format does not understand, or do not result in a thorough, of course, or at least show up, so most are right, but something is wrong!
There are many online bmp file format, but they put it thorough enough, cause actual total go some detours.
bmp is a common image format is widely used. Recently when dealing with ui library to learn under bmp format, also found at some of the pit, record.
bmp format is simple, online search a pile, also described on Wikipedia, I will not repeat here,
The most important document is the first, mainly the first 54 bytes, UE can look at bmp:
note:
1. The contents of the red box is the key
2. a numerical value, are lower front, comprising pixels behind. For example, RGB888 order is actually stored BGR888
Color: There are several standard, RGB is a common one of very easy to understand, so the focus is below the standard RGB color.
Since the 4-color, black and white, 16 colors, 256 colors, color distortion too, except for special occasions, now rarely used, so I do not how to try.
For 256 colors, in fact, there is the concept of the drawing board, you can enhance photo quality, reduce storage space, are interested can go to find the next
Focus on that: 16-bit color 24-bit color
Note the difference: 16 color and 16-bit color, 16-color is 16 colors, very monotonous; 16-bit color, that is expressed with 16bit color, 65,536 colors, rich.
24 is a 24bit color to represent the color, then there are 256 * 256 * 256 colors, the colors richer, meet most normal use.
Since 24-bit color so well, why we are using 16-bit color it? Even lower color? The main applications are not the same, the fewer digits, the worse the performance results of course, but accounted for less storage space, it means faster processing, display requirement is not so high in places, still quite a market, another color display objects have also been limited, and there's people should know that the old screen is monochrome, so no amount of color ultimately 0 or 1; subsequent emergence of color screen, but the color is also very little, so few, but better than monochrome a much better effect; then later appeared true color, it allows us to enter the age of 888, of course, after more and more brilliant color. In short, the color depends on your device / processing capacity / hardware costs.
He said before color RGB888 is 24 = 8 + 8 + 8
16-bit color is? RGB565 = 5 + 6 + 5, there RGB555 = 5 + 5 + 5, more general RGB565.
"In our image computer are the RGB888 format image, stored in each pixel 24 in FIG 32bit data, i.e., RGB888 + Alpha, Alpha stuff byte is translucent ......" equipment but which, we often use RGB565 Therefore between the two is to be converted, the conversion algorithm, online a lot, it is very simple, is not repeated here.
Of course, not actually so simple, I encountered such a pit by pit, had a good understanding of BMP format.
I do not know you have not noticed 001EH bmp format in the meaning here:
0 - no compression (expressed using BI_RGB)
1 - RLE 8- 8-bit RLE compression (indicated by BI_RLE8)
2 - RLE 4- 4-bit RLE compression (indicated by BI_RLE4)
3 - Bitfields- bit field storage mode (indicated by BI_BITFIELDS) is generally used bit12 and bit32, here is the key! Focus! Focus! Focus!
Because the target file is RGB565,16bit, so here to fill 001E 3, be careful not to fill 0! Be careful not to fill 0! Be careful not to fill 0!
Then fill the 3 whether to OK it? Not! Because 16bit, there RGB565 and RGB555 two standards, you have to tell each other in what format! Otherwise, the system silly!
So tell the system how it? We need to add some information after the original 54 byte, 16-byte main content increases:
Red placeholder RGB565 to fill: 0x0000F800
green to fill the placeholder RGB565: 0x000007E0
blue occupying RGB565 to fill: 0x0000001F
due into 70 bytes, so the offset / length change to reflect the local values
There is a place: 000EH this place to be an increase of 16, here to fill in 0x38!
Thus, if it is RGB555, then, these places have to be changed
There is also a pit is bmp to 4-byte alignment, would have been well understood, but actually it is
"Each row had to 4-byte alignment, filled with insufficient 00H"
for example:
If the image is 51 * 51 format: RGB565 (a pixel of 2 bytes)
The number of bytes per row = 51 * 2 = 102 bytes, 102 is not a multiple of 4, so to compensate both 00, so that 104 bytes =
Here I give a head to create a bmp function, you can implement your own bmp head, because usually it is used with RGB565 RGB888 two types so do not consider other types, if interested can improve the following code to make it more versatile!
. 1 // pTitle fixed 70 bytes, create 2 // byBits digits, such as 24 16 . 3 // nWidth image width (number of pixels) . 4 // nHeight image height (number of pixels) . 5 // nFileLen total pixel image * nHeight nWidth point = . 6 void CreateBmpTitle ( byte * pTitle, byte byBits, UINT nWidth, UINT nHeight, UINT nFileLen) . 7 { . 8 int nPos = 0 ; . 9 Memset (pTitle, 0 , 70 ); 10 . 11 // for each pixel how much of byte 12 byte bmpBytes =2 ; 13 if (byBits <= 8 ) 14 { 15 bmpBytes = 1 ; 16 } 17 else if (byBits <= 16 ) 18 { 19 bmpBytes = 2 ; 20 } 21 else if (byBits <= 24 ) 22 { 23 bmpBytes = 3 ; 24 } 25 else 26 { 27 = bmpBytes . 4 ; 28 } 29 30 // each row must be put together. 4 31 is UINT nLineLen nWidth * = bmpBytes; 32 IF ((nLineLen% . 4 !) = 0 ) 33 is { 34 is UINT Nadd = ( . 4 - (nLineLen% . 4 )) * nHeight; 35 nFileLen + = Nadd; 36 } 37 [ 38 is pTitle [nPos ++] = ' B ' ; 39 pTitle [nPos ++] = ' M' ; 40 41 is // file length 42 is SetUINT_L (nFileLen + 70 , pTitle, nPos); 43 is nPos + = . 8 ; // Reserved 4 skip 44 is 45 // offset 46 is SetUINT_L ( 70 , pTitle, nPos); 47 nPos + = . 4 ; 48 49 // Windows, 56 is 50 SetUINT_L ( 56 is , pTitle, nPos); 51 is nPos + = . 4 ; 52 is 53 is // width 54 SetUINT_L(nWidth,pTitle,nPos); 55 nPos += 4; 56 //高度 57 SetUINT_L(nHeight,pTitle,nPos); 58 nPos += 4; 59 //平面数=1 60 SetUSHORT_L(1,pTitle,nPos); 61 nPos += 2; 62 63 //bits 数 64 SetUSHORT_L((USHORT)byBits,pTitle,nPos); 65 nPos += 2; 66 67 if(byBits == 24) 68 { 69 nPos + = . 4 ; 70 } 71 is the else IF ((byBits == 16 ) || (byBits == 15 ) || (byBits == 32 )) 72 { 73 is // BI_BITFIELDS 74 SetUINT_L ( . 3 , pTitle, nPos) ; 75 nPos + = 4 ; 76 } 77 78 // content length, must be a multiple of 4 79 SetUINT_L (nFileLen, pTitle, nPos); 80 nPos + = 4 ; 81 82 SetUINT_L ( 0xb12 , pTitle, nPos); 83 nPos + = . 4 ; 84 85 SetUINT_L ( 0xb12 , pTitle, nPos); 86 nPos + = . 4 ; 87 88 IF (byBits == 16 ) 89 { 90 // 565 RGB respectively bits where bit 91 is nPos = 54 is ; 92 93 SetUINT_L ( 0xF800 , pTitle, nPos); 94 nPos + = . 4 ; 95 96 SetUINT_L (0x07E0 , pTitle, nPos); 97 nPos + = . 4 ; 98 99 SetUINT_L ( 0x001F , pTitle, nPos); 100 nPos + = . 4 ; 101 } 102 103 104 /// other are zero 105 }