Nice! This would probably do even better if the color space was linear-- it should reduce how much the highlights (e.g. the sun) are lost.
ThumbHash: A better compact image placeholder hash
11–20 of 123 posts
Re: ThumbHash: A better compact image placeholder hash
#12This may be a super dumb question but... how is this better than using progressive jpegs?
Looks smoother, transparency, data small enough to inline in the HTML or JSON payload, supports not just JPEGs but also PNGs, WebPs, GIFs.
IMO I don't really care for a 75%-loaded progressive JPEG. Half the image being pixelated and half not is just distracting.
Re: ThumbHash: A better compact image placeholder hash
#13Cool tech, but i feel that for all even remotely modern connection types placeholders like this are obsolete and do nothing but slow down showing the real thing.
Re: ThumbHash: A better compact image placeholder hash
#14This may be a super dumb question but... how is this better than using progressive jpegs?
You call an API -> it returns some json with content and links to images -> you start doing a new request to load those images -> only when partially loaded (aka on request 2) you will see the progressive images starting to form.
With this: You call an API -> it returns some json with content and links to images and a few bytes for the previews -> you immediately show these while firing off requests to get the full version.
So I'm thinking quicker to first draw of the blurry version? And works for more formats as well.
Re: ThumbHash: A better compact image placeholder hash
#15What I’ve seen instagram and slack do is create a really small jpg and inline that in the API response. They then render it in the page and blur it while the full size image loads. Placeholder image ends up being about 1KB vs the handful of bytes here but it looks pretty nice Everything is a trade off of course, if you’re looking to keep data size to a minimum then blurhash or thumbhash are the way to go
> Everything is a trade off of course, if you’re looking to keep data size to a minimum then blurhash or thumbhash are the way to go
Isn’t that optimizing for load speed at the expense of data size?
I mean the data size increase is probably trivial, but it’s the full image size + placeholder size and a fast load vs. full image size and a slower load.
Re: ThumbHash: A better compact image placeholder hash
#16This may be a super dumb question but... how is this better than using progressive jpegs?
1. If the thing that's going to be loaded isn't a JPEG, but rather a PNG, or WebP, or SVG, or MP4...
2. These are usually delivered embedded in the HTML response, and so can be rendered all at once on first reflow. Meanwhile, if you have a webpage that has an image gallery with 100 images, even if they're all progressive JPEGs, your browser isn't going to start concurrently downloading them all at once. Only a few of them will start rendering, with the rest showing the empty placeholder box until the first N are done and enough connection slots are freed up to get to the later ones.
Re: ThumbHash: A better compact image placeholder hash
#17I hate these blurry image thumbnails, much prefer some sort of hole, and just wait for a better thumbnail (look at youtube for this, or basically any site). I'd much rather see engineers spending more time making the thumbnails load faster (improving their backend throughput, precache thumbnails, better compression, etc). The blurry thumbnails have 2 issues 1) trick person into thinking they're loaded, especially if…
What I find more of an issue cognitively is that they entice to discern their contents, but of course they are too blurry to really see anything and trigger the subliminal feeling that you forgot to put your glasses on. So they attract your attention while typically not providing much useful information yet. A non-distracting neutral placeholder is generally preferable, IMO. Even more preferable would be for images to load instantly, as many websites somehow manage to do.
Re: ThumbHash: A better compact image placeholder hash
#18Cool tech, but i feel that for all even remotely modern connection types placeholders like this are obsolete and do nothing but slow down showing the real thing.
And this is why everything is slow and terrible. Because us developers use fast machines on fast connections, and assume everyone else does.
Travel to some far flung parts of the world, and see if your hypothesis holds true.
Re: ThumbHash: A better compact image placeholder hash
#19This may be a super dumb question but... how is this better than using progressive jpegs?
A few things that immediately come to mind:
- you can preload the placeholder but still lazy load the full size image
- placeholders can be inlined as `data:` URLs to minimize requests on initial load, or to embed placeholders into JSON or even progressively loaded scripts
- besides placeholder alpha channel support, it also works for arbitrary full size image formats
Re: ThumbHash: A better compact image placeholder hash
#20I don't understand why it is only for <100x100 images. Isn't the blurring useful for larger images? what's the point of inlining small ones?