[Enhancement] UX improvement - provide album cover placeholder when the actual cover is being downloaded

[pawelmalak]

Every time we open albums view/grid we get this flash of "unstyled content" - default album covers. It takes a while to load all of them, even on local network. With lots of albums, you can see as they get populated one by one.

This feature request proposes to provide simplified version of album cover with the initial albums data, so they can get rendered with the album grid. This can be achived by storing cover thumbnail in base64 format or by using something like blurhash.

This is how it looks in the photoview app. They use it for photos in the album but the same approach can be used for the album covers.

Updating album cover should also update its placeholder.

[ildyria]

Todo:

• : add blur_hash column to size_variants
• : add step to generate blur_hash from thumb & small
• : add console command to generate blur_hash from already existing images
• : add diagnostic info check to count number of blur_hash missing
• : insert blur_hash in thumbnail

Questions

• : add JS decoding implementation ??
• : compute base64 image & store it in DB (replace blur_hash) ??

[aSouchereau]

Interested in this...

Looking into it, computing our own base64 images is doable, the trade off being efficiency. In manual testing I was able to reduce an image to around 100B by down-scaling to 16x16 and converting to webp (32x32 at ~135B would be better for higher fidelity and colours). I think this would be acceptable, it would require hundreds of thumbnails to make any significant impact on page load. Compared to blurhash which is only 20-30B and similar quality. However, to address the additional size, we could add a config option to disable the placeholders altogether, for those who need it.

The only downsides to Blurhash I can think of is the decoding implementation v.s. base64 being handled directly by the browser and that it would require separate dependencies for encoding / decoding.

I'm willing to implement either option, whatever we decide is best.

[ildyria]

Looking into it, computing our own base64 images is doable, the trade off being efficiency. In manual testing I was able to reduce an image to around 100B by down-scaling to 16x16 and converting to webp (32x32 at ~135B would be better for higher fidelity and colours). I think this would be acceptable, it would require hundreds of thumbnails to make any significant impact on page load. Compared to blurhash which is only 20-30B and similar quality. However, to address the additional size, we could add a config option to disable the placeholders altogether, for those who need it.

The only downsides to Blurhash I can think of is the decoding implementation v.s. base64 being handled directly by the browser and that it would require separate dependencies for encoding / decoding.

I'm willing to implement either option, whatever we decide is best.

I am currently in the middle of rewriting the front-end. See #2504 and #2485.

If you integrate this in the backend, I will make it in the front-end.
Either of the option is fine with me and I do agree with the disabling config.

Implementation specific, I would consider adding that as an SizeVariant with index 7
(see SizeVariantType and SizeVariant).
In both case, the short_path should be either the hash or base64 string (assuming the later fits in the DB).

[ildyria]

Done well by @aSouchereau