The results are pretty impressive. I wonder if the general idea can be applied with a bit more data than the roughly 21 bytes in this version. I know it's not a format that lends itself to be configurable. I'd be fine with placeholders that are say around 100-200 bytes. Many times that seems enough to actually let the brain roughly know what the image will contain.
ThumbHash: A better compact image placeholder hash
71–80 of 123 posts
Re: ThumbHash: A better compact image placeholder hash
#72It looks like this has a bias for vertical banding that blurhash doesn't have, is that intentional?
Re: ThumbHash: A better compact image placeholder hash
#73I 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).
If it's really that simple, looking forward to your github repo that gives folks the JS and Rust libraries to do that =)
Re: ThumbHash: A better compact image placeholder hash
#74Hello! 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…
Are you Evan? Thanks so much for your work in open source - your GitHub avatar is easily recognized! :)
Re: ThumbHash: A better compact image placeholder hash
#75ThumbHash? 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 agree. Calling it a hash function feels off.
I do not expect a hash function's output to be used to 'reverse' to an approximation of the input (which is the primary use here). That being easy is even an unacceptable property for cryptographic hash functions, which to me are hash functions in the purest form.
I would rather call this extreme lossy compression.
Re: ThumbHash: A better compact image placeholder hash
#76Earlier 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.
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
Re: ThumbHash: A better compact image placeholder hash
#77Hello! 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…
Are you Evan? Thanks so much for your work in open source - your GitHub avatar is easily recognized! :)
No kidding. Just to consider a single project, my total time saved using esbuild instead of pure JS bundlers could probably be measured wallclock months, and I really like the way it's written: simple, approachable, handwritten lexer/parser, etc. The way that esbuild organizes its lexer state has infected my handrolled lexers, too.
Re: ThumbHash: A better compact image placeholder hash
#78An 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...
Re: ThumbHash: A better compact image placeholder hash
#79Blurring images or doing any sort of maths on the RGB values without first converting from the source-image gamma curve to "linear light" is wrong. Ideally, any such generated image should match the colour space of the image it is replacing. E.g.: sRGB should be used as the placeholder for sRGB, Display P3 for Display P3, etc... Without these features, some images will have noticeable brightness or hue shifts. Shown…
> 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.
This shouldn't matter as long as everything is tagged with the real colorspace; it'll get converted.
If you forget to do that you can have issues like forgetting to clip floating point values to 1.0 and then you get HDR super-white when you expected 100% white.
Re: ThumbHash: A better compact image placeholder hash
#80I 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…
> The blurry thumbnails have 2 issues 1) trick person into thinking they're loaded
But is _not_ showing blurry thumbnails during image loading any better in that regard?
- an empty area would give the false impression there isn't any image at all
- a half-loaded image would give the false impression the image is supposed to be like that / cropped
- if e.g. the image element doesn't have explicit width and height attributes, and its dimensions are derived from the image's intrinsic dimensions, there will be jarring layout shifts
> 2) have a meaning that content is blocked from viewing
For you maybe. And even when so, so what? Page context, users' familiarity with the page, and the full images eventually appearing will make sure this is at most is only a temporary and short false belief.