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

111–120 of 123 posts

Re: ThumbHash: A better compact image placeholder hash

#111

Post by a-dub »

shakna wrote: post #97
a-dub wrote: post #81

Earlier quoted context omitted.

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!

Perceptual hashing wouldn't seem to satisfy your second requirement there, either.

it does, it just works on estimates of percepts rather than bits.

you can think of a perceptual hash as two functions. a perceptual function that maps differing collections of bits that appear the same or similar to the same bits, and then a traditional hash function to ensure that these intermediate values get shuffled.

Re: ThumbHash: A better compact image placeholder hash

#112

Post by a-dub »

mholt wrote: post #89
a-dub wrote: post #81

Earlier quoted context omitted.

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, w…

sure. but think about it this way: most real world data is actually highly structured. in the space of bits that aren't encrypted, the real stuff lives in a very, very small subspace and good hash functions seek to avoid collisions in their output.

Re: ThumbHash: A better compact image placeholder hash

#113

Post by emptysea »

Doxin wrote: post #99
emptysea wrote: post #3

What 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

As far as I know just about any file format other than JPEG is better at this. If I recall correctly you basically want to go with GIF if your thumbnail has less than 255 pixels total.

just tested this and the jpeg ends up being 690 Bytes while the gif ends up being 2 KB

Re: ThumbHash: A better compact image placeholder hash

#114

Post by 8n4vidtmkvmk »

eyelidlessness wrote: post #93
8n4vidtmkvmk wrote: post #90

Earlier quoted context omitted.

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.

I just recently did some work in a much less sophisticated area of this. For folks who want to efficiently juggle image data into and out of canvas, ImageBitmap is a little known web API that does it very well. Unlike most web APIs dealing with binary data that interfaces with user interaction, you can use it synchronously, and it’s vastly more efficient than juggling base64-blobs-URLs.

That was the 'blip it onto the canvas' approach :D I discovered that ImageBitmap type just recently too, it's been very handy for the little project I'm working on. My data still comes as base64 strings in JSON though.

Re: ThumbHash: A better compact image placeholder hash

#115

Post by 8n4vidtmkvmk »

explaininjs wrote: post #92
8n4vidtmkvmk wrote: post #90

Earlier quoted context omitted.

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.

No reason to transfer the image data in JSON, just read the response as an ArrayBuffer. Pass over that and write it into a dataURI with the needed modifications in a single go.

How are you going to do that? There's other things in the payload. If it was just the image in the response you could read it as binary, but remember we want lots of tiny images coupled with titles and other metadata. You can use something other than JSON but it'll need some kind of structure that needs parsing.

Re: ThumbHash: A better compact image placeholder hash

#116

Post by explaininjs »

8n4vidtmkvmk wrote: post #115
explaininjs wrote: post #92

Earlier quoted context omitted.

No reason to transfer the image data in JSON, just read the response as an ArrayBuffer. Pass over that and write it into a dataURI with the needed modifications in a single go.

How are you going to do that? There's other things in the payload. If it was just the image in the response you could read it as binary, but remember we want lots of tiny images coupled with titles and other metadata. You can use something other than JSON but it'll need some kind of structure that needs parsing.

I don't see how it would ever need to be more than a single pass over the data. Sure the logic might be mildly complicated, but nothing CPU intensive.

Re: ThumbHash: A better compact image placeholder hash

#117

Post by georges_gomes »

canucker2016 wrote: post #84
jws wrote: post #38

Earlier quoted context omitted.

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

This technic is very interesting. I imagine quite effective and very small JavaScript decoded.

Re: ThumbHash: A better compact image placeholder hash

#118

Post by IvanK_net »

edflsafoiewq wrote: post #110
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.

Wow, nice! I wrote a BC1 encoder in JS, it is quite simple :) https://github.com/photopea/UTEX.js/blob/master/UTEX.js#L198

Re: ThumbHash: A better compact image placeholder hash

#119

Post by eyelidlessness »

8n4vidtmkvmk wrote: post #114
eyelidlessness wrote: post #93

Earlier quoted context omitted.

I just recently did some work in a much less sophisticated area of this. For folks who want to efficiently juggle image data into and out of canvas, ImageBitmap is a little known web API that does it very well. Unlike most web APIs dealing with binary data that interfaces with user interaction, you can use it synchronously, and it’s vastly more efficient than juggling base64-blobs-URLs.

That was the 'blip it onto the canvas' approach :D I discovered that ImageBitmap type just recently too, it's been very handy for the little project I'm working on. My data still comes as base64 strings in JSON though.

Yeah you’re gonna have to async once to get the binary thing canvas works well with, but if it’s even remotely stable you can just memoize shuttling ImageBitmap back in as needed. For my use case it was just literally redrawing the same background image things get drawn on top of with an internal data structure that translates to canvas API. Switching from async calls to ImageBitmap basically made the difference between “this flickering is making me question medical facts about myself” and “I can see it lag if I’m trying really hard”. Which isn’t great but it’s more than good enough for what I was trying to solve.

Re: ThumbHash: A better compact image placeholder hash

#120

Post by javier2 »

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…

It is very cool. I exactly want to use it as a placeholder in a large grid of small images!
Post reply on HN