4 ms·

Is the space savings of using a custom base83 encoding really worth it when modern browsers can natively support base64 image encodings?

PostOnce 4y ago
base85 is already fairly widely supported also in libraries for many languages, its in python's standard lib https://en.wikipedia.org/wiki/Ascii85 https://en.wikipedia.org/wiki/Ascii85
jerjerjer 4y ago
It's base83 hash, not base83 image so using base64 won't help any.
- trinovantes 4y ago
  It seems more like a modified version of jpg compression which also uses DCT. Why not just downsample the original image to 10x10 jpg and encode it as base64 so it can be directly used in an <img> without blocking your main JS thread to decode the image? Apply css blur if you like the soft gradient effect.
  - nicoburns 4y ago
    Because a raster format is going to be very inefficient for storing a gradient
    - trinovantes 4y ago
      Both formats are trying to encode the parameters of cosine functions except jpg is implemented natively in web browsers, likely with SIMD instructions. Is the ~200 bytes in savings per image really worth the extra computation cost you're passing onto your users?
      - mark-r 4y ago
        I wonder if you could use Javascript to convert the hash into a full JPEG and get the best of both?
        trinovantes 4y ago
        It's unlikely since the smallest possible jpg 10x10 jpg is just under 300 bytes. You might be able to squeeze out a few dozen bytes if you tried multiple browser supported formats (e.g. jpg, webp, png, gif) and pick the smallest one since they might be better at encoding blurhash's gradient effect.
        mark-r 4y ago
        I'm sorry, I wasn't clear about what I meant. The idea was to convert the hash to JPEG once it reached the client, so that the browser's native JPEG support could be used to display and cache the image.
mark-r 4y ago
In this case it looks like a key consideration is the way each data point fits into exactly 2 characters, no tricky bit manipulation going on. I'd say it's pretty clever.

PostOnce 4y ago

base85 is already fairly widely supported also in libraries for many languages, its in python's standard lib https://en.wikipedia.org/wiki/Ascii85 https://en.wikipedia.org/wiki/Ascii85

jerjerjer 4y ago

It's base83 hash, not base83 image so using base64 won't help any.

trinovantes 4y ago
It seems more like a modified version of jpg compression which also uses DCT. Why not just downsample the original image to 10x10 jpg and encode it as base64 so it can be directly used in an <img> without blocking your main JS thread to decode the image? Apply css blur if you like the soft gradient effect.
- nicoburns 4y ago
  Because a raster format is going to be very inefficient for storing a gradient
  - trinovantes 4y ago
    Both formats are trying to encode the parameters of cosine functions except jpg is implemented natively in web browsers, likely with SIMD instructions. Is the ~200 bytes in savings per image really worth the extra computation cost you're passing onto your users?
    - mark-r 4y ago
      I wonder if you could use Javascript to convert the hash into a full JPEG and get the best of both?
      - trinovantes 4y ago
        It's unlikely since the smallest possible jpg 10x10 jpg is just under 300 bytes. You might be able to squeeze out a few dozen bytes if you tried multiple browser supported formats (e.g. jpg, webp, png, gif) and pick the smallest one since they might be better at encoding blurhash's gradient effect.
        mark-r 4y ago
        I'm sorry, I wasn't clear about what I meant. The idea was to convert the hash to JPEG once it reached the client, so that the browser's native JPEG support could be used to display and cache the image.

mark-r 4y ago

In this case it looks like a key consideration is the way each data point fits into exactly 2 characters, no tricky bit manipulation going on. I'd say it's pretty clever.