[yread]

Still super bloated compared to the tiniest GIF:

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...

[Someone]

That’s bloated ;-)

   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.

[daxterspeed]

If we permit the fairly recent QOI format[0] we can produce a 1x1 transparent pixel in just 23 bytes (14 byte header, 1 byte for QOI_OP_INDEX, 8 byte end marker):

  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.