47 49 46 38 39 61 01 00 01 00
00 ff 00 2c 00 00 00 00 01 00
01 00 00 02 00 3b
http://probablyprogramming.com/2009/03/15/the-tiniest-gif-ev...
47 49 46 38 39 61 01 00 01 00
00 ff 00 2c 00 00 00 00 01 00
01 00 00 02 00 3b
http://probablyprogramming.com/2009/03/15/the-tiniest-gif-ev...
P1
1 1
1
is a 9 byte 1 × 1 pixel black image in portable bitmap format (https://en.wikipedia.org/wiki/Netpbm#File_formats). Consumers of such files likely will know how to scale them to 256 × 256 pixels. The trailing newline may not even be necessary. If so, it would become 8 bytes.Gray 1 X 1 pixel images in binary portable graymap format have the same size. To get a non-gray RGB color, you’ll need two more bytes in binary portable pixmap format.
71 6f 69 66 00 00 00 01 00 00 00 01 04 00 | 14 byte header
00 | QOI_OP_INDEX
00 00 00 00 00 00 00 01 | end marker
Similarly the 103 byte png in the article would be [EDIT] This is incorrect, see below 71 6f 69 66 00 00 01 00 00 00 01 00 04 00 | 14 byte header
fe b7 d0 d0 | QOI_OP_RGB, RGB color,
fd fd fd fd c6 | QOI_OP_RUN for 62+62+62+62+7
00 00 00 00 00 00 00 01 | end marker
[0]: https://qoiformat.org/qoi-specification.pdf[EDIT] I realized that we actually run into one of QOI's drawbacks if we were to encode the 103 byte png in the article, as we actually need to repeat the pixel 65535 times, so we'd have floor(65535/62)=1057 QOI_OP_RUN bytes followed by another QOI_OP_RUN to repeat the last pixel. Here it's pretty clear that the QOI spec missed out on special handling of repeated QOI_OP_RUN operators, as long repetitions could have been handled in far fewer bytes.