These are quite terrific. I really like these because I hate movement on page load. This one looks pretty good too.
ThumbHash: A better compact image placeholder hash
21–30 of 123 posts
Re: ThumbHash: A better compact image placeholder hash
#22Cool 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.
Until you don't have that connection somewhere.. Plus it will still work when your CDN / image processing server is having troubles.
Re: ThumbHash: A better compact image placeholder hash
#23I don't understand why it is only for <100x100 images. Isn't the blurring useful for larger images? what's the point of inlining small ones?
Probably because the algorithm is really slow and you’re already producing a really small image so scaling your original image down before isn’t too much work
Blurhash is really slow on larger images but quick with small <500x500 images
Re: ThumbHash: A better compact image placeholder hash
#24On the examples given, it definitely looks the best of all of them, and seems to be as small as or smaller than their size I'm not really sure I understand why all the others are presented in base83 though, while this uses binary/base64. Is it because EvanW is smarter than these people or did they try to access some characteristic of base83 I don't know about?
Unlike b64-encoding, b83-encoding is nontrivial in CPU time (it's not just a shift-register + LUT), so you don't want to be doing it at runtime; you want to pre-bake base83 text versions of your previews, and then store them that way, as encoded text. Which means that BlurHash does that on the encode side, but more importantly, also expects that on the decode side. AFAIK none of the BlurHash decode implementations accept a raw binary; they only accept base83-encoded binary.
While the individual space savings per preview is small, on the backend you migh be storing literally millions/billions of such previews. And being forced to store pre-baked base83 text, has a lot of storage overhead compared to being able to storing raw binaries (e.g. Postgres BYTEAs) and then just-in-time b64-encoding them when you embed them into something.
Re: ThumbHash: A better compact image placeholder hash
#25Cool 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.
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.
Re: ThumbHash: A better compact image placeholder hash
#26What 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
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
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)
Re: ThumbHash: A better compact image placeholder hash
#27First of all, I love the idea and I think it's very creative.
As for my impression, but I don't think the blurry images is impressive enough to load an additional 32 kB per image. I think the UX will be approximately the same with a 1x1 pixel image that's just the average color used in the picture, but I can't test that out.
Re: ThumbHash: A better compact image placeholder hash
#28I don't understand why it is only for <100x100 images. Isn't the blurring useful for larger images? what's the point of inlining small ones?
Probably because the algorithm is really slow and you’re already producing a really small image so scaling your original image down before isn’t too much work Blurhash is really slow on larger images but quick with small <500x500 images
Thanks, even if I'm not the one who asked. I guess the longer version of your answer would be "if you have larger input, just downscale first". And for the quality demands, you wouldn't even miss any antialiasing, just sample every nth pixel for a n00xn00 image, should really be good enough.
I wonder if it might be nice to allocate some more bytes to the center than to the edges/corners? Or is this already done?
Re: ThumbHash: A better compact image placeholder hash
#29Cool 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.
One pervasive source of slow connections, even in well-developed places, is mobile devices as they travel in a car or public transit.
Re: ThumbHash: A better compact image placeholder hash
#30Cool 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.
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.
Well, yes and no. There is lots of waste for sure, but this is really just not warranted. Honestly i'm not sure it ever was. Even 15-20 years ago actual pictures loaded just fine. And don't get me started on text placeholders..