I built SplatHash. It's a lightweight image placeholder generator I wrote to be a simpler, faster alternative to BlurHash and ThumbHash.
[1] I used my own avatars and icons as a test set. For example, https://avatars.githubusercontent.com/u/323836?s=400&v=4
Can you share what are the reasons someone may want to compress and image to 16 bytes?
The trick of using common huffman and quantization tables for multiple images has been done for a long time, notably Flash used it to make embedded JPEGs smaller (for when they were saved at the same quality level).
At 16 bytes per image, you can use this for even gigantic libraries with only a few megabytes. It becomes reasonable to just download and keep it all in memory at all times, so you can always show something vaguely representational instantly, rather than nothing but thousands of identical empty boxes. Often this is just a small nice-to-have bit of visual flair, but it can be useful too: I've been happy to have it when I was looking for moon pictures I knew I had taken, on a slow network, and they were super obvious to scroll to without having to wait for hundreds/thousands of thumbnails to download to find the right area. Instead I immediately found the dozen-ish I wanted and only had to download those to figure out the exact file I was looking for. (they're pretty easy to spot when you have a dozen that all look kind of similar in a row, compared to a whole bunch of things with wildly different colors for the rest of the week)
You can do similar things for showing placeholders on images in a website: it's so small you can just keep it right on the database row, and it won't be a performance or space concern on essentially any database, even for millions of users.
When you save a series of images as 16x16 JPEGs at the same JPEG quality level without optimization, you notice that there is a whole lot of common data between those files. Common data includes things like the file header (FF D8, FF E0 blocks), the Quantization tables, and the Huffman tables. If you cut away all the common data, the actual size of the image data is extremely tiny, usually under 64 bytes, though not a fixed size.
Here are the sizes of the four example images (just the unique image data) when resized to 16x16, then saved at quality 20:
First image: 48 bytes
Second image: 42 bytes
Third image: 31 bytes
Fourth image: 35 bytes
After appending back the 625 bytes of common data, you end up with a regular JPEG that can be decoded and displayed using fast native code from the browser.
ThumbHash page includes a comparison against "Potato WebP" which is probably a similar idea.