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

81–90 of 123 posts

Re: ThumbHash: A better compact image placeholder hash

#81

Post by a-dub »

Aeolun wrote: post #69
a-dub wrote: post #42

ThumbHash? seems more like MicroJPEG maybe? hash implies some specific things about the inputs and outputs that are definitely not true! cool idea to extract one piece of the DCTs and emit a tiny low-res image though!

I think this is very much a one way operation, which would imply some form of hash?

regular (non-secure) hash functions do two things: they compress (very lossily) and they make things that are near each other in their domain (inputs) map to things that are far apart in their codomain (outputs).

the first condition is satisfied, but the second is definitely not!

Re: ThumbHash: A better compact image placeholder hash

#82

Post by tshaddox »

nextaccountic wrote: post #76
tshaddox wrote: post #57

Earlier quoted context omitted.

I'm not really sure that sentiment applies here. People on slow or unreliable connections probably aren't going to rejoice that they get to see blobs of color for a while until the full images load, all for the cost of waiting longer for the full images and loading more total data at the end of the ordeal.

> all for the cost of waiting longer for the full images and loading more total data at the end of the ordeal. Thumbhash is tiny (like, 28 bytes base64) and can be embedded in the html itself Replacing all your CSS class names by one or two letter names would save multiple times this amount even on tiny websites, but I'm not seeing nobody doing this

CSS class names probably don't benefit much unless you're on such low end hardware that you're worried about client gzip costs (and at some point we have to determine some reasonable floor to client capabilities). These embedded thumbnails would presumably be essentially incompressible.

Re: ThumbHash: A better compact image placeholder hash

#83

Post by franciscop »

constexpr wrote: post #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…

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.

Re: ThumbHash: A better compact image placeholder hash

#84

Post by canucker2016 »

jws wrote: post #38
codetrotter wrote: post #9

Earlier 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

As you get to small image sizes, the relative size of the quantization table and the Huffman encoding table becomes significant. You can easily just pick a standard version of these, leave them out of the image (which is no longer a valid JPEG), and then put them in at the destination to make a valid JPEG again. I'm not finding a source, but I think I remember the tables being in the 1-2kB range. Cheap MJPEG USB came…

Mentioned the FB blog post in my comment to this post. I didn't see any mention of the size of the fixed tables.

see https://news.ycombinator.com/item?id=35268708

Re: ThumbHash: A better compact image placeholder hash

#85

Post by Scaevolus »

franciscop wrote: post #83
constexpr wrote: post #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…

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.

Re: ThumbHash: A better compact image placeholder hash

#86

Post by 8n4vidtmkvmk »

fiddlerwoaroof wrote: post #53
constexpr wrote: post #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 is cool. Do you happen to know if the thumbhash string has other uses? Perhaps grouping images by similarity or something?

I was thinking about that too. Can't answer the question, but I did come across this just the other day: https://github.com/cloudinary/ssimulacra2 Supposedly good for comparing image similarity. Might depend on your use-case, I think it's geared towards image quality moreso than similar photos.

Re: ThumbHash: A better compact image placeholder hash

#87

Post by 8n4vidtmkvmk »

imhoguy wrote: post #36
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 these issues can be solved by just rendering a spinner or "loading" text on top of the blurred image.

Definitely don't want 100 spinners over a grid of images.

Re: ThumbHash: A better compact image placeholder hash

#89

Post by mholt »

a-dub wrote: post #81
Aeolun wrote: post #69

Earlier quoted context omitted.

I think this is very much a one way operation, which would imply some form of hash?

regular (non-secure) hash functions do two things: they compress (very lossily) and they make things that are near each other in their domain (inputs) map to things that are far apart in their codomain (outputs). the first condition is satisfied, but the second is definitely not!

> > they make things that are near each other in their domain (inputs) map to things that are far apart in their codomain (outputs).

This is describing a specific subset of hash only. *Cryptographic* hash functions map inputs to outputs with high and uniform dispersion.

So you are talking about cryptographic hashes, but different hash functions can have different properties.

ThumbHash is absolutely a hash function, which is "any function that can be used to map data of arbitrary size to fixed-size values, though there are some hash functions that support variable length output." (https://en.wikipedia.org/wiki/Hash_function)

Re: ThumbHash: A better compact image placeholder hash

#90

Post by 8n4vidtmkvmk »

explaininjs wrote: post #39
degenerate wrote: post #26

Earlier quoted context omitted.

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)

The claim being that the act of concatenating some bytestrings together is a massive time sink?

Decode from base64 json, concat, convert to a Blob, createObjectURL and feed back into an img? That's about the simplest way I can think to do it. Either that or blip it onto a canvas. Or convert it back to base64 in the form of a data-URI.
Post reply on HN