Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Not sure why I would want to use this instead of progressive image decoding with a (CSS?) blur filter. Instead of a blurred image suddenly flashing to a fully loaded image, the user would see the image quality gradually improve as it loads over the network.

Then again, progressive JPEG or FLIF is not supported that well anywhere, so I guess this could be the best thing right now because it seems to just require HTML5 canvas.



A blurhash is much easier to send along with the JSON data used to display the initial page. To see a blurred version of a progressive JPEG the browser must have first started to download that JPEG. When there are many JPEG's to download, it may not even have started downloading yet.


I typically store it in the DB along with the image ID (or URL). It's being displayed even before network request to the actual image has started. Works like a charm on slow networks.


Store what? The BlurHash ?


Correct. It's just 20-30 bytes of data.


Mastodon, for example, use it to defer loading of images tagged with Content Warning until the user clicked reveal. It provides a useful context for user to decide whether to view the image, while not require browsers/clients to load the image beforehand.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: