Thread: Image height = -16

I'm reading header info from a bitmap. I can get the image width and bit-depth fine but the height comes out as -16. I am almost certain that this problem is caused by me reading bytes from the file as char type, but I cant work out how to get it to read as Uint8. Aslo the way I am doing this is probably unnecessarily complicated. Heres my code:

Code:

int Image::LoadBMP(char* filename)
{
	ifstream in;
	in.open(filename, ios::binary);
	if(! in.is_open()) return LOAD_IMAGE_INVALID;
	
	char i[4];

	in.seekg(18, ios::beg);
	in.read(i, 4);
	w=(i[3]<<24)+(i[2]<<16)+(i[1]<<8)+i[0];
	
	//in.seekg(22, ios::beg);
	in.read(i, 4);
	h=(i[3]<<24)+(i[2]<<16)+(i[1]<<8)+i[0];

	in.seekg(2, ios::cur);
	in.read(i, 2);
	bpp=(i[1]<<8)+i[0];

	in.close();
	return IMAGE_LOAD_SUCCESS;
}

Any suggestions on a working/better way to read this data?

Nah, I already tried that but it wont seem to work. I'd get errors when I call in.read() saying:

Code:

error C2664: 'std::basic_istream<_Elem,_Traits>::read' : cannot convert parameter 1 from 'unsigned char [4]' to 'char *'

Probably the endian ordering. I had a similar problem when reading dimensions for a terrain file. I had to do shifts each time I read a byte until I recieved the proper value.

Is a BMP really big-endian? Either way, shifting a (signed) char will not give you what you want. Cast the chars to unsigned before you shift them, or make the whole array unsigned and cast it to a regular char * when you call get().

Personally, I'd write a small inline function which takes a char [4] and returns an unsigned 32-bit integer. Call it "unpack32BitBigEndian" or something. No need to duplicate the same code over and over.

Hmm, I thought I sorted that out with all the bitshifting I'm doing.

Also my test image has a height of 240. And -16 as a char would be something like 239 as Uint8.

Originally Posted by mike_g

Hmm, I thought I sorted that out with all the bitshifting I'm doing.

The code you have now is treating the byte sequence as big-endian -- the first byte gets shifted to the MSB. But the real problem is the signed shift.

EDIT: And the bit patterns for (unsigned char)240 and (signed char)-16 are the same bit pattern, so it's definitely the problem.

Thanks brewbuck, that fixed it. I'm casting it to Uint8 just before the bitshifting. As in:

Code:

w=((Uint8)i[3]<<24)+((Uint8)i[2]<<16)+((Uint8)i[1]<<8)+(Uint8)i[0];

But would there be a cleaner way to write this? It looks kind of messy.

[edit]Oh and how do I get if the machine is big endian or not?

Thanks[/edit]

Originally Posted by mike_g

But would there be a cleaner way to write this? It looks kind of messy.

Like I said, contain the messiness in a function which does this for you.

Oh and how do I get if the machine is big endian or not?

It has nothing to do with the endianness of your machine -- the shifting method protects against your MACHINE'S endianness. It has to do with the endianness of the FILE FORMAT.

Ok cool, i'll just chuck it in a function. and forget about the endian thing then

Originally Posted by mike_g

Ok cool, i'll just chuck it in a function. and forget about the endian thing then

Well I'm kind of concerned that a Microsoft Windows file format would be big-endian. I don't have the BMP spec or know where to get one, so I don't know for sure, but I suspect the format is actually little-endian, like most Windows computers. I COULD BE WRONG THOUGH.

The difference between reading a big-endian and a little-endian value is simple, the indexes go [3], [2], [1], [0] for big-endian and [0], [1], [2], [3] for little-endian.

Just to be clear, the shifting method makes sure that you get the right value taking into account your machine's endianness. You still have to deal with the endianness of the data source itself.

Originally Posted by Salem

Almost all file formats can be found by typing "foo file format" into a search engine.
http://www.wotsit.org/ for example.

I'm fairly paranoid about file formats. If I can't prove to myself that what I'm looking at is "THE spec" I don't tend to trust it very much. When you're dealing with an MS spec things get even more... interesting.

wotsit.org is very reliable when it comes to file formats.

I've loaded thousands of BMPs and usually when a value in the header is not reading correctly it is caused by byte alignment in the header structure.

I've never come across a negative height for a BMP but keep in mind the BMP format has so many variations it's nearly impossible to account for them all w/o writing an entire library. This is why Windows has functions specifically for loading BMPs.