• Some users have recently had their accounts hijacked. It seems that the now defunct EVGA forums might have compromised your password there and seems many are using the same PW here. We would suggest you UPDATE YOUR PASSWORD and TURN ON 2FA for your account here to further secure it. None of the compromised accounts had 2FA turned on.
    Once you have enabled 2FA, your account will be updated soon to show a badge, letting other members know that you use 2FA to protect your account. This should be beneficial for everyone that uses FSFT.

wierd BMP parse problem

S

Stuh505

Limp Gawd
Joined
Feb 15, 2004
Messages
488
I have written code to parse BMP images to put the intensity values into a matrix

I'm experiencing a very very wierd problem: if the size of the BMP is a nice power of 2 like 8x8, then it works fine. but if the BMP size is like 7x7, I get big problems

most noticeably, the number of rows that are actually storing the pixels seems to be slightly less than the actual number of rows in the BMP...causing the image to "slant"

additionally, pixel values are not preserved. for instance, if my image was all pure white (255) with a single pixel black line down the center (0), then it will be slanted (and the slope is not always 1, sometimes it is a more like 0.3)...and additionally, there will be values between 0 and 255 surrounding this line.

The only thing I can imagine is that there is some form of compression occuring at certain filesizes...but the BMP header file says compression=0
 
I'm gonna go on pure speculation here so take it w/ a grain of salt.

Seems some sort of word/block alignment problem which would explain the skew you're getting. It may also explain why it works for nice even numbers. Have you tried an image that is a multiple of 2 but not 4? Off the top of my head I'm gonna guess that BMP likes each line to be a multiple of 4.

Imagine w/ a 7x7 image ... (r,g,b = 1 byte)

RGB RGB RGB RGB RGB RGB RGB 000 (21 bytes, padded w/ 3 zero bytes to make 24)
RGB RGB RGB RGB RGB RGB RGB 000

But 8x8

RGB RGB RGB RGB RGB RGB RGB RGB (no padding)

So If you were going to read line by line, you'd want to round the xSize of the image to the next largest multiple of 4 and use that as your scan/run length or however you want to think about it.
 
i may be pitching stupid info up here you already know, but did you compensate for the header?

i was writing some stuff in C and my initial problem lied there. just making sure. good luck
 
You must log in or register to reply here.
Back
Top