BMP write produces a skewed image

[GoogleCodeExporter]

Saving a 280x68 BMP will produce an image that seems to have the row stride
off by one making the image skew to the right. Additionally, Windows
Explorer shows a warning icon next to the thumbnail indicating an erroneous
file. PNG etc. will save fine.

Additionally, enlarging the image to e.g. 1000x200 will result in same
skewing but the image data being offset near center of the image (see
attached image).

Milestone-2.1 OpSys-Windows

Original issue reported on code.google.com by kometb...@gmail.com on 23 Dec 2009 at 2:46

Attachments:

• bug.png

[GoogleCodeExporter]

I think this was already fixed in r1195. Did you try one of the WIP builds ? 

Original comment by pulkoma...@gmail.com on 23 Dec 2009 at 3:11

[GoogleCodeExporter]

The Dec 01 WIP does the same when saving. However, after a look at the r1195 
commit I
realized this doesn't happen if I change the image width to a multiple of 4.

I would be suspicious of the fact line_width is set to the next multiple of 
four but
the file header receives the real non-multiple-of-four width.

header.Width    =Main_image_width;

Original comment by kometb...@gmail.com on 23 Dec 2009 at 3:40

[GoogleCodeExporter]

Ok, so the bug isn't perfectly fixed. The header holds the right value, only 
the 
storage of pixel data is affected by the multiple-of-4 thing.

Do you see this problem when loading back the picture in grafx2, or when 
looking at 
it with another tool ? or both ?

Original comment by pulkoma...@gmail.com on 23 Dec 2009 at 4:02

[GoogleCodeExporter]

Yep, it is skewed when loaded in any program.

I read about BMP a bit and the code certainly looks like it's like it should 
be. The
data should be aligned to 4-byte boundaries but no document says also the image 
width
should also be aligned. When I examine the proper BMP saved with Paint it seems 
to
have 4 bytes less padding per line compared to the Grafx2 saved version of the 
same file.

Original comment by kometb...@gmail.com on 23 Dec 2009 at 5:03

[GoogleCodeExporter]

Ok I think the way the existing code tries to get the next multiple of four is 
off. A
better and probably more clear way to get the next multiple is something like 

line_width = original_width

if (line_width & 3)
  line_width = (4 - (line_width & 3)) + line_width

Original comment by kometb...@gmail.com on 23 Dec 2009 at 5:13

[GoogleCodeExporter]

Fix applied in r1240. Seems to work for me. Tell us what you find out.

Original comment by pulkoma...@gmail.com on 23 Dec 2009 at 5:34

[GoogleCodeExporter]

Ok, I can't reproduce the bug anymore. Thanks.

Original comment by kometb...@gmail.com on 23 Dec 2009 at 6:32

[GoogleCodeExporter]

Original comment by pulkoma...@gmail.com on 23 Dec 2009 at 7:00

• Changed state: Fixed