OTA Bitmap encoding/decoding likely incorrect when width % 8 != 0

[mstoeckl]

The current image-extras encoder and decoder for the OTA Bitmap format appears to incorrectly handle (rare) images whose width is not a multiple of 8.

Quoting the description of MR introducing the format: #2:

Note that OTA Bitmap Wikipedia article differs from ImageMagick implementation for the format (ImageMagick splits rows at bytes - padding with 0s, while Wikipedia explicitly claims this is not the case). (OTA Bitmap Wiki, ImageMagick implementation) I have gone with an implementation consistent with ImageMagick, but the implementation consistent with the Wikipedia is easier, so if there is any evidence that the latter is valid I would be happy to switch it back.

I have not been able to find any example OTA Bitmap images which are not 72 pixels wide, but the specification for OTA Bitmap (the Smart Messaging Specification 3.0.0, Section 3.7, indirect link) agrees with Wikipedia. The relevant line:

In order to fully utilise the available bandwidth no filler bits are used in the end of the row; fillers are put at the end of the whole bitmap if the size of the bitmap is not divisible by eight. Filler bits assume a value of zero.

I only found one non-ImageMagick implementation handling images with width not divisible by 8, in Kannel; matching the spec, it only pads at the end of image and not at the end of the rows.

[RunDevelopment]

Nice investigation! 🕵️‍♂️

I agree and our implementation and the implementation of ImageMagick are wrong. The spec clearly says what to do on page 29, and we do something else. I think this should be fixed.

We should probably also file a bug report with ImageMagick. They don't seem to know about this issue yet.

---

On the topic of OTB being wrong: Wikipedia says:

The format has a maximum size of 255x255 pixels.

However, the spec says that the width and height field are 8 or 16 bits long (Table 3.7-1). This seems to be controlled via a bit in the info field. The wiki you linked calls this an "extension", but the spec doesn't seem to say it's optional. Should we support this too?

[mstoeckl]

Should we support this too?

The OTA Bitmap format is both obsolete and rare, so I would generally advise only implementing features for it if you have strong evidence that such images exist or are needed by someone.

(It is entirely possible that there are no existing OTB images that people can access that use a width or height of >255; format specifications can include features or behaviors that aren't used in practice, weren't supported except by a single implementation, or weren't actually implemented as described. In that case, writing a new decoder or encoder is doing unnecessary work, and risks doing something incompatible with the original format. Like padding rows incorrectly :-)