One other thing to compare it against is actual tiny JPEGs.
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.
Interesting, but my testing suggests that SplatHash is very weak at preserving global features, at least for synthetic images [1]. Both BlurHash and ThumbHash were able to preserve most of them, at the expense of worse (but still non-zero) local feature reproduction, but SplatHash simply discarded all global features! I guess you need to store both local features (Gaussian splats) and global features (cosine bases) for the best result. The currently unused padding bit might be useful for that...
Very cool. To my eye, the splats are sometimes having too much contrast -- implying more "stark" visual features that don't actually manifest in the real image. Presumably the radius and the opacity curve of the gradients can be tuned to taste at the decoding phase, to make the splats softer?
The 6 blobs of colors look very weird after testing a few images, I feel like ThumbHash is much more natural and the downsides are minimal compare to SplatHash.
I've seen the alternative where you make a tiny JPEG file (discarding the huffman and quantization tables), and use that as the placeholder. Just glue the header and tables back on, and let the browser handle JPEG decoding and stretching. It's not as small as 16 bytes, but the code for handling it is fast and simple.
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).
As a game engine dev, if I have an asset management app, it’s pretty reasonable that it might load the list of asset names and hashes before doing the significant work of decoding/generating thumbnails. This could give the app instant low quality thumbnails from loading the tiny array of data that’s already necessary just to get started.
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.
[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).