FILE *filePtr;
BITMAPFILEHEADER bitmapFileHeader;
unsigned char * bitmapImage;
int imageIdx = 0;
unsigned char tempRGB;
filePtr=fopen("fire.bmp","rb");
fread(&bitmapFileHeader,1, sizeof(BITMAPFILEHEADER), filePtr);
if (bitmapFileHeader.bfType != 0x4D42)
{
fclose(filePtr);
return NULL;
}
fread(bitmapInfoHeader, sizeof(BITMAPINFOHEADER),1,filePtr);
LoadBitmaps problem
Author
Hey, I've been trying to write function which loads bmp file to string.
Starting code is following:
Are you using the structs from windows.h or your own creations?
If it's your own make sure you get the padding right (BITMAPFILEHEADER has its members packed to 16bit).
Also note that the biSizeImage is not necessarily set to a valid value, it may as well be 0.
In any case the values you show are off. Either the wrong padding has led to interpreting the wrong bytes as biSizeImage or the BMP is corrupt.
If it's your own make sure you get the padding right (BITMAPFILEHEADER has its members packed to 16bit).
Also note that the biSizeImage is not necessarily set to a valid value, it may as well be 0.
In any case the values you show are off. Either the wrong padding has led to interpreting the wrong bytes as biSizeImage or the BMP is corrupt.
Author
I'm using structures from windows.h so sizes are ok: BITMAPFILEHEADER has 16 bytes
BITMAPINFOHEADER has 40 bytes so I suppose bitmapFileHeader.bfOffBits should have had 56 but as I mentioned have 2621440. I tried several bitmaps and on each one function loads big, strange values to headers.
BITMAPINFOHEADER has 40 bytes so I suppose bitmapFileHeader.bfOffBits should have had 56 but as I mentioned have 2621440. I tried several bitmaps and on each one function loads big, strange values to headers.
Ok, in that case is the code you showed the exact code you use?
Because there is no & at
fread( bitmapInfoHeader, sizeof(BITMAPINFOHEADER),1,filePtr);
I'd use a hex viewer and actually compare all members if they match the file content. This should let you find the actual problem pretty fast.
Because there is no & at
fread( bitmapInfoHeader, sizeof(BITMAPINFOHEADER),1,filePtr);
I'd use a hex viewer and actually compare all members if they match the file content. This should let you find the actual problem pretty fast.
Author
So I fixed my function and now it is
fread(&bitmapInfoHeader, sizeof(BITMAPINFOHEADER),1,filePtr);
but it doesn't change the situation.
I noticed that sum of fields of struct BITMAPFILEHEADER is 14 not 16
because there is: short + long + short + short + long (2+4+2+2+4=14)
In addition when I'm looking at size of bitmap file 128x128 in properties it is 49206
which would confirm my idea because 128*128*3 + 14 + 40=49206
maybe there is a problem in here and data read from headers is simply moved 2 bits to the left. But on the other hand it would mean that bitmap structures from windows.h are incorrect what is impossible.
fread(&bitmapInfoHeader, sizeof(BITMAPINFOHEADER),1,filePtr);
but it doesn't change the situation.
I noticed that sum of fields of struct BITMAPFILEHEADER is 14 not 16
because there is: short + long + short + short + long (2+4+2+2+4=14)
In addition when I'm looking at size of bitmap file 128x128 in properties it is 49206
which would confirm my idea because 128*128*3 + 14 + 40=49206
maybe there is a problem in here and data read from headers is simply moved 2 bits to the left. But on the other hand it would mean that bitmap structures from windows.h are incorrect what is impossible.
That's the problem right there. The structs padding seems to be set for 32bit.
The Windows headers define a pack pragma around the BITMAPFILEHEADER struct which ought to set the padding to 16bit.
What compiler are you using?
If yours doesn't work with that pragma you have to resort to read the struct members manually (member by member).
The Windows headers define a pack pragma around the BITMAPFILEHEADER struct which ought to set the padding to 16bit.
What compiler are you using?
If yours doesn't work with that pragma you have to resort to read the struct members manually (member by member).
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement