Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

ThumbHash: A better compact image placeholder hash

evanw.github.io

Post reply on HN
Print view View original

101–110 of 123 posts

Re: ThumbHash: A better compact image placeholder hash

#101

Post by bajsejohannes »

constexpr wrote: post #50
detrites wrote: post #45

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.

Yep. Here's a good description of the issue, with examples that will show if the browser is the problem: https://magnushoff.com/articles/jpeg-orientation/

Re: ThumbHash: A better compact image placeholder hash

#104

Post by nedt »

attah_ wrote: post #13

Cool 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.

When Facebook did it years ago (plus their slim version of the web page) they mentioned India as one important use case. Huge country, a lot of people, but not even remotely a "modern connection". Also other "remote" countries like Australia have worse network performance. Of course you could say you don't care about APAC, but that's not how websites should be build.

Re: ThumbHash: A better compact image placeholder hash

#105

Post by kurtextrem »

transitivebs wrote: post #54

I open sourced a version of what Evan calls the "webp potato hash" awhile back: https://github.com/transitive-bullshit/lqip-modern I generally prefer using webp to BlurHash or this version of ThumbHash because it's natively supported and decoded by browsers – as opposed to requiring custom decoding logic which will generally lock up the main thread.

Small heads-up, you might want to look at the PRs (I've opened the single open PR) :D

Take a look here: https://github.com/ascorbic/unpic-placeholder. Recently created by a Principal Engineer of Netlify, which kind of server-side-renders BlurHash images, so that they don't tax the mainthread. Maybe the same can be done for ThumbHash (I've opened an issue in that repo to discuss it)

Re: ThumbHash: A better compact image placeholder hash

#106

Post by Aachen »

munro wrote: 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…

When browsing DCIM via sshfs, I'd kill for using this instead of having to wait for it to read every 3MB image and generate a thumb to show me. I don't have a problem with current thumbs because the status quo of waiting 30 seconds for a page of images to get thumbed is so terrible. Probably I'd love the improvement if it would use ThumbHash server-side^W phone-side instead of small pngs or whatever it does today.

Re: ThumbHash: A better compact image placeholder hash

#107

Post by franciscop »

Scaevolus wrote: post #85
franciscop wrote: post #83

Earlier quoted context omitted.

I have a bigger budget and would love higher quality, would it be possible easily to adapt the code to ouput 50-100 bytes strings in a similar fashion (2x-4x), or it'd be a complete rewrite? I read the JS code but unfortunately I'm really unfamiliar with low level byte manipulation and could not make heads or tails out of it.

Try very small webp images. 32x32 quality 5 webp images are around 100-150 bytes.

Given the difference in quality seen, I'd guess Thumbhash at 50 bytes would be similar quality to webp at 100-150 bytes, so basically 1/3rd of the size or 3x the quality for "the same price". The examples of webp are way worse quality, and almost 2x the size.

Re: ThumbHash: A better compact image placeholder hash

#108

Post by kevincox »

canucker2016 wrote: post #78

An order of magnitude smaller than Facebook's 200 byte goal for preview photos in their graphql responses. see https://engineering.fb.com/2015/08/06/android/the-technology...

Although the FB images do have much higher fidelity. So it is a tradeoff.

Re: ThumbHash: A better compact image placeholder hash

#109

Post by deadbeeves »

crazygringo wrote: post #65
munro wrote: 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 they're great, and it's not much different from progressive image loading that's been around for decades. Images going from blurry to sharp was a big thing back in the 1990's over dial-up AOL and MSN. > I'd much rather see engineers spending more time making the thumbnails load faster Generally it's a client-side bandwidth/latency issue, not something on the server. Think particularly on mobile and congested…

>it's not much different from progressive image loading that's been around for decades

Progressive images suck. PNG's implementation is particularly awful, as you have to use increasing amounts of brainpower to tell whether it has finished loading or not.

Re: ThumbHash: A better compact image placeholder hash

#110

Post by edflsafoiewq »

IvanK_net wrote: post #66

I think they should siply use four patches of BC1 (DXT1) texture: https://en.wikipedia.org/wiki/S3_Texture_Compression It allows storing a full 8x8 pixel image in 32 Bytes (4 bits per RGB pixel).

Nice idea. I tried it, it works really well: https://imgur.com/a/p3l6ABh

A software decoder would be tiny and you can use an existing good BC1 encoder.

Post reply on HN