The first capture group shall be a format. The currently recognized formats are `gb`, `r16`, and `r85`, though any format can be used. A program SHOULD gracefully report and exit on an unknown or unsupported format. The identifier of a format may not include a hyphen (dash).
The second capture group (optional) shall be known as the header and its syntax shall be defined by the format, but if present it MUST contain exactly one hypen and it must be the last character in the header.
Upon receiving a message containing the part, a compliant client MAY take steps to attempt a conversion to PNG or similar, or display the image inline. A thread with timeout CAN and SHOULD be used.
While there is no theoretical limit to the size of the image you can send, you are bound by any message length limits your server sets, as the entire part MUST fit in one message.
The header has this syntax: `r'(\d+).(\d+).(\d+)-'`. The first and second capture groups specify the width and height of the image and the third group specifies the bitdepth.
The header has this syntax: `r'(\d+).(\d+).(\d+)-'`. The first and second capture groups specify the width and height of the image and the third group specifies the bitdepth.
The payload is an (Adobe) ascii85-encoded representation of the image data. It has this syntax: `r'(<~[!-uz]+~>)'`.
8x8, monochrome
See https://en.wikipedia.org/wiki/Ascii85#Example_for_Ascii85 for the encoding. See `ruby-ascii85` package in Debian for an implementation. TODO: see https://www.dcode.fr/ascii-85-encoding for a non-Adobe implementation that will save at least four bytes.
