back to blog index

Image quines

These are 2 code-golfed C programs which print their own source code (the definition of a quine, really). However, these are no regular quines: instead of simply printing their source code as text, they instead print a screenshot of themselves, as would be seen by viewing their source code in xterm.

There's 2 of them because I had 2 different targets: the shortest file whose output format could reasonably be called an image, and the shortest file whose output was a PNG. The output format for the first one was PBM, simply because it's the simplest format I knew of that was actually recognized by most image viewers.

The PBM quine's code is:

"``m/`pj2^0owt2^/ohhb2^oo/sh?^?^v0ba0bv^^5b^^a0bv0ba^",h[99999]="h1 480 208 ",*g
"k--;)*f++=*a-94;for(*h=80;1280>u;u++)for(j=13;j--;)for(k=6;k --;l=p[u])h[j*480"
"+u/80*6240+k+u%80*6+11]=49-(j*l?c[l*12+j-(64>l?385:709)]>>k:0)%2;puts(h);} ",p[

imgquine_pbm.c (1225 bytes)

And it produces the following image:

The PNG version's source code is:


imgquine_png.c (1849 bytes)

And the output is:

Note that you'll get a lot of warnings when trying to compile this. In the future, some of those warnings might even get upgraded to errors. So if you're reading this from the future, then know that the last compilers this was tested with were GCC 10.2 and Clang 10.0.

So here's how it works. We'll start with the PBM one, as the PNG version is pretty much an extension of it. char* a is the font, encoded as RLE with one set of characters acting as repeat counts and another set acting as actual data. The data is encoded as 5 bits per character, with each character giving one scanline of one letter of the font. The font is 6x13, but the first row and leftmost column of each character are blank, so we only need to encode a 5x12 region for each character. Also, the font doesn't cover the entire printable ASCII range, only what was needed to represent the rest of the source code. This created a bit of a dilemma, as some characters were only needed because they were used by the description of other characters in the font. I ended up running a small brute-force search for the best parameters (i.e. ones which required the fewest extra bytes to represent).

(TODO: more explanation here)

Now that we know how the PBM one works, here's what I needed to change to make it output PNGs. I got around PNG's compression by simply encoding the image data as a sequence of raw (or literal, or non-compressed) blocks. Deflate (the compression algorithm used in PNG) supports them to allow for minimal overhead when trying to compress already-compressed data: it only requires a 5-byte header to write up to 65KB of data to the output stream. However, there's nothing that checks whether the image data inside a PNG is actually well-compressed, so we can get away with encoding the entire uncompressed image data as raw blocks. This of course goes against the entire point of the PNG file format, but I'm not going to implement an actual compressor inside a quine.

There are still 2 obstacles that make the PNG variant significantly more complicated than the PBM variant: checksums. The Deflate stream includes an Adler-32 checksum, and the PNG file format mandates a CRC-32 checksum too. Adler-32 uses integer arithmetic and is much shorter to implement in plain C than CRC-32 with its polynomial rings over GF(2). So we just update the Adler-32 checksum as we compute the pixels of image data. For the CRC-32 sum, however, we can cheat: the "32" in its name signifies that the checksum itself is only 32 bits long. And as we all know, 32 bits can only encode one of around 4 billion values. So we can simply hardcode the CRC in our program, and generate random variations of the quine until one of them has the right CRC.

Lastly, I want to thank a few friends who provided invaluable help while golfing this, and without whose support I wouldn't have finished this at all: