wbmp(file-format)
Full name Wireless Application Protocol Bitmap Format. It's an image format used for the WAP protocol. Only one format is defined (1-bit white and black, similar to P4 PBM), no one bothered to define more since the WAP protocol turned out to be a total failure later and every phone and infrastructure becomee good enough (and with ISPs fighting for more customers with cheaper data plans) to directly use HTTP anyway.
Format
| Field name | Field type | Size (in bytes) | Purpose |
|---|---|---|---|
| Type | uintvar* | variable | Type of the image. As of WAP standard version 24-May-1999, only type 0 is defined (for uncompressed 1-bit black and white bitmap) |
| Fixed header | byte | 1 | Used to describe the "Extension header" (see below). For image type 0, this field would be 0, meaning no extension header fields are specified. |
| Extension header | byte | variable | Extension header. See below. |
| Width | uintvar* | variable | Width of the image in pixels. |
| Height | uintvar* | variable | Height of the image in pixels. |
| Data | byte array | variable. | Dependent on the type of the image.** |
uintvar
The "uintvar" in this case refers to a format that uses sequences of bytes to represent an arbitrarily large unsigned integer. Different variants exist, but the one used in WBMP goes as follows:
- Each byte within an uintvar consists of 1 bit of "continuation flag" and 7 bit of the original number.
- The continuation flag is at the most significant bit. If this bit is 1, the next byte is still a part of the same number; if this bit is 0, the current byte would be the last byte.
- All bits are in big-endian. For example, if a big integer ended up taking up the space of 3 bytes using this representation, the last 7 bits of the first byte contains the first 7 bits of that number, the second byte the second 7 bits, etc.. If the number somehow cannot be represented by a number of bits that is a multiple of 7, zeroes are padded at the left-end (or most significant) side.
For example, the integer 0x60 (0b01100000; 96) would be represented in this scheme as the byte sequence 0x60, since it only takes up 7 bit long and thus does not require multiple bytes; the integer 0xa0 (0b10100000; 160), on the otherhand, needs to, since it takes up 8 bits. Because 8 is not a multiple of 7, zeroes are padded at the left-end, which makes it 0000001 0100000; continuation flags are added accordingly resulting in 10000001 00100000, thus the representation of 0xa0 in uintvar would be the sequence 0x81 0x20.
Fixed header and extension header
Fixed header is defined to be of size 1 bytes. Each bits within this byte contains the following meanings:
| Bit (7 being most significant) | Description |
|---|---|
| 7 | Extension header flag. 1 means there will be extension header fields. 0 means there will be not. |
| 6-5 | Extension header type (see below) |
| 4-0 | Reserved |
The extension header type may be of any of the following value with meanings as follows:
- Type 00 (bit6=0, bit5=0): indicates a multi-byte bitfield used to specify additional header information. The first (i.e. most significant) bit is set if more data for the additional header follows. The other bits are reserved for future use.
- I don't believe anyone ever used Type 11 extension header, since WAP basically died before it could ever catch on and only the one image type that doesn't use any extension header is ever defined.
Data
As mentioned above, the actual arrangement of the data for pixels depens on the image type. For image type 0, data bytes are arranged in rows first (from left to right) then column (from top to bottom) with one bit per pixel. A black pixel is denoted by 0 and a white pixel is denoted by 1. If the length of the row (i.e. the width of the image) is not divisible by 8, each row is padded with zeroes at the right-end.
2025.3.27