Ordering from top-bottom or bottom-top

[JorgosCoenen]

I discovered this via Jimp, but posting here seems more directly relevant.

I didn't know this, but apparently the data in a BMP can be ordere top-to-bottom or bottom-to-top. This would be visible in the biHeight.
My MacOS doesn't seem to care either way, but when I tried displaying a BMP generated through Jimp (via bmp-js) on a low-resolution display through a C library (RaspberryPi), it failed and reported a negative image height. When I re-converted the image with XnConvert, it did work.

Console log from the C library:
BMP_cfSize:1800054
BMP_cfoffBits:54
BMP_ciSize:40
BMP_ciWidth:1200
BMP_ciHeight:-500 <---------------------
//etc.
total_length:1800000,1800000
bytesPerLine = 3600
imageSize = -1800000

When I posted on StackOverflow, GregHNZ pointed me towards the negative height in encoder.js. I changed this to positive and now the image displays through the C library on the low-res screen just fine.
I just had to flip the image in Jimp with image.flip(false, true) to maintain the right orientation.

I don't know if this is intended behaviour, and maybe this is a real edge case, but maybe good to document, and perhaps turn into a variable?

[SamJakob]

Yes this is a real edge case. Traditionally Microsoft bitmaps are stored bottom-to-top, however there is a convention of sorts that if you wish to store a top-to-bottom bitmap, you set the height to be negative true height.

In other words, positive height means bottom-to-top whereas negative height means top-to-bottom. In both cases, the height is the magnitude of the height value.

[dejavu1987]

I had the same issue, I created a pr to fix just that #41