Skip to content

Determine album art dominant colors to reduce flicker in the interface#9

Merged
ruuda merged 14 commits intomasterfrom
thumb-color
May 3, 2025
Merged

Determine album art dominant colors to reduce flicker in the interface#9
ruuda merged 14 commits intomasterfrom
thumb-color

Conversation

@ruuda
Copy link
Copy Markdown
Owner

@ruuda ruuda commented May 2, 2025

As described in this toot:

In Musium I have instant search, and it shows album thumbnails. Even when they are cached, they are not always displayed instantly. I suppose because the browser has to decode the image again, and this lead to subtle but noticeable flickering effect, especially on mobile.

So I implemented a feature where for every album cover, I extract the dominant color (not the average color!), and use that as a placeholder. Now the flickering is less apparent!

(The effect is exaggerated in the videos.)

Before After
https://github.com/user-attachments/assets/617055b5-7716-43e0-ad1e-84d7e985ecbb https://github.com/user-attachments/assets/5dcf880f-9f77-4f1f-8e94-6ef1f6fd8c81
https://github.com/user-attachments/assets/462bd904-62ce-4dc1-bed0-9f280ef8b28c https://github.com/user-attachments/assets/52e767d5-c6b3-433a-9010-67269acb8fd0

ruuda added 13 commits May 1, 2025 09:59
I noticed in search, in the discographies where it shows many images,
they take a few milliseconds to show up, and it makes them flicker into
view which is ugly. I already added a grey backdrop, but it's still
visible. I wonder if it would help to select a better background color
that is more aligned with the thumbnail. Then I got a bit nerd-sniped
on extracting that color, and I think I have a good algorithm now. Now
we need to run that and store it in the database, and then later we can
serve it in the webinterface in the response json.

I suspect the reason for the flicker is not loading the image, because
they are cached, but either decoding or downscaling it. I suppose the
browser evicts it from memory and then has to decode it again.

This commit adds an analysis step to the thumbnail pipeline, but it does
not do anything with that information yet.
It happens to fit in the Album struct nicely!

This is a breaking change that requires recomputing all thumbnails.
Testing with Chromium devtools, caching disabled and severely throttling
the network, this works amazingly well! The visual pop when a picture
loads is still visible, but scrolling the list now feels much more
solid, just the color itself already says so much about the album!
Helix formats it on save, and it's annoying to have to "git add -p" all
the time. Time to reformat it.
Better to deal with this at parse time and store things uniformly in the
database. This does require repopulating the database.
This ensures that we pick up the thumbnail colors after the thumbs are
computed, but also the loudness, which previously was not properly
reloaded! That meant that loudness normalization didn't work for new
albums if you never restarted Musium or re-scanned the collection!
It interprets the string '413e42' as the number 4.13e+44. Bizarre.
And also the search fix that I implemented as a drive-by now that I had
to change that logic anyway.
@ruuda ruuda merged commit dc88c6a into master May 3, 2025
1 check passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant