consider using thumbhash

[eikaramba]

see https://evanw.github.io/thumbhash/ for a better explanation. seems to generate better LQIPs(way better quality, same or lower file/base64 size) - not sure if imagetools library needs to implement this or you can hook this up directly here https://github.com/zerodevx/svelte-img/blob/master/src/lib/vite.js#L6

[zerodevx]

Hey, that's an interesting idea. I experimented with blurhash before, and iirc there's a huge performance hit of run-time rendering of the hash representation, compared to the native rendering of a potato-webp LQIP background. Also requires javascript, while native does not. Drawback is the webp is up to double the byte size. Quality may be improved by applying a backdrop-filter like so: https://github.com/zerodevx/svelte-img#blurred-image-placeholders

not sure if imagetools library needs to implement this or you can hook this up directly here https://github.com/zerodevx/svelte-img/blob/master/src/lib/vite.js#L6

Yup I think we probably can hook it up directly.

Definitely still interested to look into this once I get a moment!

[phoenisx]

Hi Folks

Thanks for this great library.
I was trying out a few scenarios using thumbhash, and comparing lqip generated by svelte-img.
I saw that the data URLs generated by thumbhash is way larger in size than svelte-img. Am I doing something wrong?? 🤔

I know the binary/base64 string generated by thumbhash is pretty small (under 30 bytes or so), but the data URL generated by it is significantly large in size.

How is lqip data URLs so small in size in this library? Is this because of using webp as format for data URLs, or because of the size used for lqip images, which is 16px, while in thumbhash examples it is 100px?

[zerodevx]

I know the binary/base64 string generated by thumbhash is pretty small (under 30 bytes or so), but the data URL generated by it is significantly large in size.

Hmm I don't really understand - thumbhash (and blurhash) images needs to be rendered at run-time i.e. browser needs to load the JS lib, decode the data string (in base64 usually around 30 chars), then render the image into the DOM. It can't be used like as an image data URI, unlike native image standards like jpg, webp etc.

[phoenisx]

Ohh!!
Thanks for helping me understand.
I thought generating data uri is required during the build to make it work.
Well generating base64 string during the build and processing it in the client makes more sense, and saves a lot of bytes 😅

Thanks for the quick response @zerodevx 🙇🏽