Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Handsum: An LQIP Image File Format

nigeltao.github.io

Post reply on HN
Print view View original

1–10 of 10 posts

Re: Handsum: An LQIP Image File Format

#4

Post by mpais »

ape4 wrote: post #3

It would be nice if the low quality image also provided a headstart for the full quality image.

Shameless plug, SQZ does just that, you can check it out at https://github.com/MarcioPais/SQZ

Also for some discussion on more technical aspects and sample images, check out the thread over at the Encode Forum: https://encode.su/threads/4183-SQZ-Low-complexity-scalable-l...

Re: Handsum: An LQIP Image File Format

#5

Post by jszymborski »

Does anyone else also feel... uneasy, bothered, it's hard to express the feeling, by LQIPs?

Primarily those that are blurry, my brain wants to figure out what the picture is, even before I recognize it's an LQIP, which is straining and frustrating because... well it's blurry or super degraded.

Is it really better than just having a placeholder square with maybe the most prominent color? Or just a good old progressive image?

Re: Handsum: An LQIP Image File Format

#7

Post by gforce_de »

interesting! 147 bytes for 128x128 pixels are ~0.096 bpp (bits/pixel).

Everything above 153x153 pixels is too small (!) to count as LQIP (lighthouse).

The "normal" way would be to use a 0.05+ bpp WEBP-image as LQIP,

which has ~600 bytes, but looks MUCH better and is widely supported:

https://show.quicky.club/results/cb/1f/a5/ddbacee070083ac5f7...

  $ echo "(8*147)/(154*154)" | bc -l
  .04958677685950413223
@dmit - please check your HTML (w3c validator is unhappy): https://nigeltao.github.io/blog/2026/wasm-handsum-example/ This is just invalid: '... width="128px" height="128px" ...'*

Re: Handsum: An LQIP Image File Format

#8

Post by brycewray »

jszymborski wrote: post #5

Does anyone else also feel... uneasy, bothered, it's hard to express the feeling, by LQIPs? Primarily those that are blurry, my brain wants to figure out what the picture is, even before I recognize it's an LQIP, which is straining and frustrating because... well it's blurry or super degraded. Is it really better than just having a placeholder square with maybe the most prominent color? Or just a good old progressive…

> Is it really better than just having a placeholder square with maybe the most prominent color? Or just a good old progressive image?

The Hugo static site generator provides a `.Colors` method[0] for doing this. It produces what one 2018 article[1] referred to as a GIP (Gradient Image Placeholder).

[0]: https://gohugo.io/methods/resource/colors/#article

[1]: https://calendar.perfplanet.com/2018/gradient-image-placehol...

Re: Handsum: An LQIP Image File Format

#9

Post by nigeltao »

childintime wrote: post #2

Is there any reason the tech is optimal to 32x32? 48x48 might be interesting also. Maybe the decoder can directly render to 48x48 or 64x64, so the size remains the same, and no upscaling is needed?

Handsum is intrinsically 16x16. Decoding to 32x32 is a two step process:

1. Decode to 16x16. This is done by the Handsum library.

2. Upscale 2x. This is done by the caller of the Handsum library (or, for the Wasm demo, by the HTML renderer).

If you want 48x48 or 64x64, just raise the 2x, in step 2, to 3x or 4x.

Re: Handsum: An LQIP Image File Format

#10

Post by nigeltao »

gforce_de wrote: post #7

interesting! 147 bytes for 128x128 pixels are ~0.096 bpp (bits/pixel). Everything above 153x153 pixels is too small (!) to count as LQIP (lighthouse). The "normal" way would be to use a 0.05+ bpp WEBP-image as LQIP, which has ~600 bytes, but looks MUCH better and is widely supported: https://show.quicky.club/results/cb/1f/a5/ddbacee070083ac5f7... $ echo "(8*147)/(154*154)" | bc -l .04958677685950413223 @dmit - please…

Hi, author here. Thanks for the "check your HTML" bug report.
Post reply on HN