[nawgz]

On the examples given, it definitely looks the best of all of them, and seems to be as small as or smaller than their size

I'm not really sure I understand why all the others are presented in base83 though, while this uses binary/base64. Is it because EvanW is smarter than these people or did they try to access some characteristic of base83 I don't know about?

[derefr]

Unlike b64-encoding, b83-encoding is nontrivial in CPU time (it's not just a shift-register + LUT), so you don't want to be doing it at runtime; you want to pre-bake base83 text versions of your previews, and then store them that way, as encoded text. Which means that BlurHash does that on the encode side, but more importantly, also expects that on the decode side. AFAIK none of the BlurHash decode implementations accept a raw binary; they only accept base83-encoded binary.

While the individual space savings per preview is small, on the backend you migh be storing literally millions/billions of such previews. And being forced to store pre-baked base83 text, has a lot of storage overhead compared to being able to storing raw binaries (e.g. Postgres BYTEAs) and then just-in-time b64-encoding them when you embed them into something.

[tolmasky]

It appears that only BlurHash is using base83. I imagine the base83 encoding is being used in the table because that is what the library returns by default.

As to why everyone else uses base64, I figure it's because base64 is what you'd have to inline in the URL since it's the only natively supported data URL encoding.

In other words, in order to take advantage of the size savings of base83, you would have to send it in a data structure that was then decoded into base64 on the page before it could be placed into an image (or perhaps the binary itself). Whereas the size savings of the base64 can be had "with no extra work" since you can inline them directly into the src of the image (with the surrounding data:base64 boilerplate, etc.) Of course, there are other contexts where the base83 gives you size savings, such as how much space it takes up in your database, etc.

[miohtama]

When encoded images are 20-30 bytes, few byte savings because of encoding seem irrelevant. But it of course depends on the context.

[nosequel]

BlurHash looks not at all accurate in the examples given. Some are not even close. I wouldn't use it on that fact alone.

[telios]

Oddly, it looks like colorspace issues, as I've had these issues intermittently with BlurHash.