What is the formula that you use to calculate the size of Photoshop bitmap files and the BITMAPFILEHEADER.bfSize member in these files?
I am asking because I am using the formula below and my BITMAPFILEHEADER.bfSize comes out 2 bytes shorter than the bitmap files produced by Photoshop.
BITMAPFILEHEADER.bfSize = sizeof(BITMAPFILEHEADER) + sizeof(BITMAP*INFOHEADER) + cbExtraBitFields + cbColorTable + cbGap + BitmapInfoHdr.biSizeImage;
cbExtraBitFields = (BitmapInfoHdr.biSize == sizeof(BITMAP*INFOHEADER)) ? ((BitmapInfoHdr.biCompression == BI_BITFIELDS) ? 3*sizeof(RGBQUAD):0) : 0;
cbGap = BITMAPFILEHEADER.bfOffBits - sizeof(BITMAPFILEHEADER) - sizeof(BITMAP*INFOHEADER) - cbExtraBitFields - cbColorTable;
BitmapInfoHdr.biSizeImage = ( (BitmapInfoHdr.biCompression == BI_RGB) || (BitmapInfoHdr.biCompression == BI_BITFIELDS) ) ? (ROUNDUP32(BitmapInfoHdr.biWidth * BitmapInfoHdr.biBitCount) >> 3) * ((DWORD)(abs(BitmapInfoHdr.biHeight))) : BitmapInfoHdr.biSizeImage ; //For BI_RGB or BI_BITFIELDS round up to the nearest DWORD boundary. Shift by 3 because there are 8 bits in a byte. (2^3=8)
//BITMAP*INFOHEADER means either BITMAPINFOHEADER or BITMAPV3INFOHEADER. The asterisk is used as a wild card (non-C notation!)
// The variable name prefix cb... denotes "Count of Bytes".
BITMAP*INFOHEADER BitmapInfoHdr; //The Declaration of BitmapInfoHdr. Will not compile because of the wildcard asterisk
#define ROUNDUP32(x) ( ((x) + 0x1F) & (~(0x1F)) ) //The macro to round up to the next multiple of 32.
The following file is a 32bpp, 32x32px image without an Alpha channel generated by Photoshop:
According to my formula:
BITMAPFILEHEADER.bfSize = sizeof(BITMAPFILEHEADER) + sizeof(BITMAPINFOHEADER) + cbExtraBitFields + cbColorTable + cbGap + BitmapInfoHdr.biSizeImage;
BITMAPFILEHEADER.bfSize = 0x0e + 0x28 + 0x00 + 0x00 + 0x00 + 0x1000; // == 0x1036 bytes
Yet in this file the BitmapInfoHdr.biSizeImage == 0x1002 and consequently BITMAPFILEHEADER.bfSize == 0x1038 bytes. Why ?
At 32bpp, the 32x32px image should take 32*32*4=4096 bytes (0x1000).
I don't understand the origin of the number 0x1002 appearing in that file. It is not even divisible by DWORD (4 bytes) - not that it needs to be a multiple of 4 for file storage purposes.
I noticed that in Photoshop bitmap files the cbGap == 0 (which is OK).