Live data from Hacker News

ThumbHash: A better compact image placeholder hash

evanw.github.io

41–50 of 123 posts

Re: ThumbHash: A better compact image placeholder hash

#43
Hello! I made this. People are talking about not wanting pictures to be initially blurry before they finish loading. I understand that too, and I'm not sure how I feel about it myself (I could go either way).

But for what it's worth, I actually made this for another use case: I have a grid of images that I want to be able to zoom really far out. It'd be nice to show something better than the average color when you do this, but it would be too expensive to fetch a lot of really small images all at once. ThumbHash is my way of showing something more accurate than a solid color but without the performance cost of fetching an image. In this scenario you'd only ever see the ThumbHash. You would have to zoom back in to see the full image.

Re: ThumbHash: A better compact image placeholder hash

#44
post #36
post #8

I 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…

I think these issues can be solved by just rendering a spinner or "loading" text on top of the blurred image.

Maybe... but solving dstraction with more distraction feels off somehow.

Re: ThumbHash: A better compact image placeholder hash

#46
post #25

Earlier quoted context omitted.

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.

If I was in a far flung part of the world I wouldn’t be perusing content rich bandwidth intensive websites. I’d be smoking a cig sitting on a worn mattress in the highest floor of an abandoned apartment building typing on a late 90s ThinkPad, negotiating prices on stolen credit card lists through encrypted IRC channels and moving illicit files on SSH servers based in foreign countries.

I'm in a far flung part of the world and a lot of my time is spent in very normal places like the AWS console, not doing any of those cool and dangerous sounding things.

Re: ThumbHash: A better compact image placeholder hash

#47

This is nice, I really like it. It 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...

Crazy idea, combine that with the technique in the submission. Use the chroma as-is, and average the traced luma with the blurry thumbnail luma.

Re: ThumbHash: A better compact image placeholder hash

#48

Hello! I made this. People are talking about not wanting pictures to be initially blurry before they finish loading. I understand that too, and I'm not sure how I feel about it myself (I could go either way). But for what it's worth, I actually made this for another use case: I have a grid of images that I want to be able to zoom really far out. It'd be nice to show something better than the average color when you do…

Nice job, a material improvement over the mentioned blur hash.

A nice CSS transition for when the image loaded would be the cherry on top ;)

Re: ThumbHash: A better compact image placeholder hash

#49

For these ultra-small sizes, I think I would go with Potato WebP since you can render it without JS, either with an tag or a CSS background. I think it looks better too.

The potato WebP had the headers stripped off. You need JS to put the headers back on.

Re: ThumbHash: A better compact image placeholder hash

#50

Anyone know why the first comparison image is rotated 90 degrees for both ThumbHash and BlurHash versions? Is this a limitation of the type of encoding or just a mistake? All other comparison images match source rotation.

That's the only image with a non-zero EXIF orientation. Which probably means you're using an older browser (e.g. Chrome started respecting EXIF orientation in version 81+, which I think came out 3 years ago?). You'd have to update your browser for it to display correctly.
Post reply on HN