ThumbHash: A better compact image placeholder hash
evanw.github.io
ThumbHash: A better compact image placeholder hash
1–10 of 123 posts
Re: ThumbHash: A better compact image placeholder hash
#2On 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?
Re: ThumbHash: A better compact image placeholder hash
#3What 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
Re: ThumbHash: A better compact image placeholder hash
#4On 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?
It appears that only BlurHash is using base83. I imagine the base83 encoding is being used in the table because that is what the library returns by default.
As to why everyone else uses base64, I figure it's because base64 is what you'd have to inline in the URL since it's the only natively supported data URL encoding.
In other words, in order to take advantage of the size savings of base83, you would have to send it in a data structure that was then decoded into base64 on the page before it could be placed into an image (or perhaps the binary itself). Whereas the size savings of the base64 can be had "with no extra work" since you can inline them directly into the src of the image (with the surrounding data:base64 boilerplate, etc.) Of course, there are other contexts where the base83 gives you size savings, such as how much space it takes up in your database, etc.
Re: ThumbHash: A better compact image placeholder hash
#5On 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?
BlurHash looks not at all accurate in the examples given. Some are not even close. I wouldn't use it on that fact alone.
Re: ThumbHash: A better compact image placeholder hash
#6On 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?
It appears that only BlurHash is using base83. I imagine the base83 encoding is being used in the table because that is what the library returns by default. As to why everyone else uses base64, I figure it's because base64 is what you'd have to inline in the URL since it's the only natively supported data URL encoding. In other words, in order to take advantage of the size savings of base83, you would have to send it…
When encoded images are 20-30 bytes, few byte savings because of encoding seem irrelevant. But it of course depends on the context.
Re: ThumbHash: A better compact image placeholder hash
#7On 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?
BlurHash looks not at all accurate in the examples given. Some are not even close. I wouldn't use it on that fact alone.
Oddly, it looks like colorspace issues, as I've had these issues intermittently with BlurHash.
Re: ThumbHash: A better compact image placeholder hash
#8I 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 there's a flicker before the blurry thumbnails are displayed!!! so then the brain has to double back and look at the new image. 2) have a meaning that content is blocked from viewing
Re: ThumbHash: A better compact image placeholder hash
#9What 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
Re: ThumbHash: A better compact image placeholder hash
#10This may be a super dumb question but... how is this better than using progressive jpegs?