First of all, I love the idea and I think it's very creative. As for my impression, but I don't think the blurry images is impressive enough to load an additional 32 kB per image. I think the UX will be approximately the same with a 1x1 pixel image that's just the average color used in the picture, but I can't test that out.
ThumbHash: A better compact image placeholder hash
31–40 of 123 posts
Re: ThumbHash: A better compact image placeholder hash
#32First of all, I love the idea and I think it's very creative. As for my impression, but I don't think the blurry images is impressive enough to load an additional 32 kB per image. I think the UX will be approximately the same with a 1x1 pixel image that's just the average color used in the picture, but I can't test that out.
Re: ThumbHash: A better compact image placeholder hash
#33First of all, I love the idea and I think it's very creative. As for my impression, but I don't think the blurry images is impressive enough to load an additional 32 kB per image. I think the UX will be approximately the same with a 1x1 pixel image that's just the average color used in the picture, but I can't test that out.
Re: ThumbHash: A better compact image placeholder hash
#34I 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…
Re: ThumbHash: A better compact image placeholder hash
#35It reminds me of exploring the SVG loader using potrace to generate a silhouette outline of the image.
Here's a demo of what that's like:
https://twitter.com/Martin_Adams/status/918772434370748416?s...
Re: ThumbHash: A better compact image placeholder hash
#36I 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…
Re: ThumbHash: A better compact image placeholder hash
#37Without these features, some images will have noticeable brightness or hue shifts. Shown side-by-side like in the demo page this is not easy to see, but when replaced in the same spot it will result in a sudden change. Since the whole point of this format is to replace images temporarily, then ideally this should be corrected.
As some people have said, developers often make things work for "their machine". Their machine on the "fast LAN", set to "en-US", and for their monitor and web browser combination. Most developers use SDR sRGB and are blithely unaware that all iDevices (for example) use HDR Display P3 with different RGB primaries and gamma curves.
A hilarious example of this is seeing Microsoft use Macs to design UIs for Windows which then look too light because taking the same image file across to a PC shifts the brightness curve. Oops.
Re: ThumbHash: A better compact image placeholder hash
#38What 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
Yep. I also remember a blog post from a few years ago about how fb removed some of the bytes in the JPEG thumbnails, because those bytes would always be the same in the thumbnails they created, so they kept those bytes separate and just added them back in on the client side before rendering the thumbnails
I'm not finding a source, but I think I remember the tables being in the 1-2kB range.
Cheap MJPEG USB cameras do this. Their streaming data is like JPEG but without the tables since it would take up too much bandwidth.
Re: ThumbHash: A better compact image placeholder hash
#39Earlier quoted context omitted.
Yep. I also remember a blog post from a few years ago about how fb removed some of the bytes in the JPEG thumbnails, because those bytes would always be the same in the thumbnails they created, so they kept those bytes separate and just added them back in on the client side before rendering the thumbnails
I both love this level of optimization (for the novelty) and hate it (knowing all the work involved is being done with JS, on my machine, costing more CPU time than the bandwidth saved)