I'm responsible for fixing a bug in a 3rd party library that's trying
and failing to read 32-bit Sun raster images output by ImageMagick.
After some investigation, I think I've stumbled onto a semi-obscure bug
in ImageMagick's code for reading and writing 32-bit Sun raster images
with odd widths. If it's not a bug, can someone explain what I'm
misunderstanding about the format? It would help me document the bugfix
in our library.
The Sun raster format specifies that rows of pixels should be padded to
be a multiple of 16 bits (in other words, an even number of bytes). For
example, for a 24-bit image with width of 3 pixels, the unpadded row
length is 9 bytes, but it should be padded up to 10 bytes. In
ImageMagick, it looks like the width in pixels is rounded up to a
multiple of two _before_ multiplying by the bytes-per-pixel, instead of
rounding up the result. In other words,
// current method
bytes_per_row = num_cols * depth / 8; // could be even at this point...
bytes_per_row += num_cols % 2; // ... but now is made odd
// "right" way?
bytes_per_row = num_cols * depth/8; // could be even at this point...
bytes_per_row += bytes_per_row % 2; // ...if not, make even
The two methods only differ semantically when depth is 16 or 32, both
admittedly obscure depths for this format. However, the current way
creates rows with odd numbers of bytes when depth is 16 or 32, which
seems to violate Sun's requirement that row lengths be multiples of 16 bits.
The "current way" above is implemented in ImageMagick 6.5.7-8 in file
coders/sun.c at lines 841-842 and 533-534 (among other places).
I think I'm probably just missing something in the spec, but if the
mistake is at my end, I've seen at least two other implementations make
the same mistake. I would much appreciate any light that could be shed
on this. Thanks!
Regards,
Kyle Simek
_______________________________________________
Magick-developers mailing list
[email protected]
http://studio.imagemagick.org/mailman/listinfo/magick-developers
