[Feature]: Blur hashes for loading pictures

[akoyaxd]

Feature detail

When scrolling fast through the timeline (on web), one can see the Name / ID of the image before it loads. I think it would be great visual improvement to load blur hashes before the thumbnail.

In the Apps, it would look better than the black boxes for fast scrolling as well.

Platform

Server

[alextran1502]

Great idea! I think this also depends on the browser that the alt value is shown when there is no picture loaded yet. I assume you use Firefox?

[akoyaxd]

Yes, I use firefox. Didn't try Chrome before, but I can confirm, that on chrome the string is not shown.

Edit: Safari doesn't show the alt value either.

[alextran1502]

I love the blur hash ideal, though; I honestly didn't know what it is called. Gonna implement this at some points

[zackpollard]

This was recommended on one of the reddit posts, looks like it has implementations for a bunch of languages 😄 https://github.com/woltapp/blurhash

[JVT038]

@bo0tzz can I be assigned to this one? I'd like to try learn a bit of Sveltekit :)

[bt90]

To add a screenshot of the current state:

[bt90]

As an interim solution, it would be nice to hide the image UUIDs.

[bo0tzz]

Another interesting alternative to blurhash is https://evanw.github.io/thumbhash/

[truongsinh]

if we have microservices, does the language implementation matter? I would imagine having a rust microservice to generate thumbhash for best performance.

[bo0tzz]

If the performance difference is really big it could be considered, but adding another container is a pretty significant cost. So far we've been using image processing libraries in nodejs, most of which (afaik) call out to C to do the work, and that's had plenty performance.

[lukehmcc]

if we have microservices, does the language implementation matter? I would imagine having a rust microservice to generate thumbhash for best performance.

I'm more thinking about rendering it in the dart app in terms of language compatibility. It would be quite annoying to have to use ffi or something to render a simple blur hash on the mobile app.

If the performance difference is really big it could be considered, but adding another container is a pretty significant cost. So far we've been using image processing libraries in nodejs, most of which (afaik) call out to C to do the work, and that's had plenty performance.

I do not think an extra container would be necessary at all. Adding extracting the blurhash during the metadata extraction task should be very easy and cheap.

[bt90]

Thumbhash is available in Javascript. Wouldn't that be easy to call from dart?

[lukehmcc]

Thumbhash is available in Javascript. Wouldn't that be easy to call from dart?

As far as I understand, js is easy to call from a web context, not as easy from a native context. (https://pub.dev/packages/flutter_js)
It would probably be smarter to use the rust bindings if we want to do thumbhash as that works better on all platforms.

[lukehmcc]

Hello there guys. I just wrote a little test app to test out the performance differences between the dart and rust libraries for thumbhash.

Turns out the performance difference is basically negligible so the added complexity of using rust is not worth it in the slightest. Also as I was writing this the dart native thumbhash library for dart has added support for encoding (as well as decoding as was previously supported).

Any who, now that I know thumbhash integration will be easy in the mobile, I'll start working on a pr to get thumbhash generation added to the metadata generation task. Then after that I'll add rendering support to the svelt site code and the mobile app.

Let me know if there's anything you guys think I should do differently while implementing (:

[lukehmcc]

I do want to note that this is for decode performance. For encode performance rust should be much faster because the dart image library is quite slow. Though the encode should be done server side afaik so this shouldn't matter. Please correct me on this if I'm wrong.

[uhthomas]

Fixed by #2649.