[API Request] Add a ThumbHash or BlurHash to the album response entity

[dweymouth]

Type of change

API extension

Proposal description

BlurHash GitHub website is a standard for encoding a placeholder for an image in a short string. It could be useful for clients to be able to display a placeholder for an album cover before the cover is loaded, especially in the case where a client is launched for the first time with an empty cover cache and the server rate limits requests to the getCoverArt API.

Backward compatibility impact

New field on the album response type. Not a breaking change

Backward compatibility

• No backward compatibility impact.

API details

The album entity (returned by endpoints such as getAlbumList2, getArtist etc.) should have a new field blurHash="<blurHashStr>". Clients may use this to show a placeholder for the cover image - that vaguely resembles the actual cover - before the image is available. It will be optional for servers to support this, and clients should have a fallback (e.g. generic placeholder image) for servers that do not return blurHashes.

Security impacts

No response

Potential issues

No response

Alternative solutions

No response

[gravelld]

Is this something the server should be dictating?

I guess, having the cover art, the server can more easily generate a representative "blur hash". But still, if the image dimensions at least were returned by the server, the client could do something with that and it might even be better; the client should dictate its own look and feel after all.

Do we want to take on that extra responsibility and bake a specific implementation like this into the API?

I might vote for this as an extension, but I'm more nervous having it as part of the first-class album API.

[Tolriq]

There's other implementations for the same purpose. The major gain is to allow clients to display a placeholder that look a lot more like what will be displayed when the full image is loaded as it can take time.
This is a nice feature to allow clients to do nice things before the actual image is available to them.
Properly done this is a nice feature.

[dweymouth]

Yes, this is especially nice for when clients are connected to a server for the first time and they have no cover images cached locally yet. With the infinite scrolling feature of my client users can connect and quickly scroll through hundreds of images before they have any time to load. I set a generic placeholder in this case, but the blurred placeholder would be much better UX.

[dweymouth]

Just want to point out that since I proposed this, a new standard https://evanw.github.io/thumbhash/ has been created which seems to be technically superior. Maybe if we add this proposal we should make it extensible, so the base64 string and an algorithm name (eg BlurHash or ThumbHash) are exposed, but we should pick one of the 2 as the standard for now.

[Tolriq]

And Kotlin ? :p

[deluan]

Sure :)

[Tolriq]

NVM there's a java version that's enough for me as a base.

[dweymouth]

I looked into thumbhash and IMO the quality of the generated images is superior than the ones created with blurhash. There's no Go version of it yet (only JS, Rust and Swift), but I'm willing to translate it to Go (and maybe C/C++) if we decide to use it.

Someone did make a go version but it's in a separate repo from the main project. It is linked to from the readme though so I think that counts as an official endorsement :)

[deluan]

That was fast! Last week it was not there :)