-
Notifications
You must be signed in to change notification settings - Fork 11
Description
Checklist
- I have filled out the template to the best of my ability.
- This only contains 1 feature request (if you have multiple feature requests, open one feature request for each feature request).
- This issue is not a duplicate feature request of previous feature requests.
Is your feature request related to a problem? Please describe.
I learned about this library in this thread, and I'm super interested in the Vibrant Color functionality.
I did this same sort of thing with NodeRED+JS a little while ago to automatically set the colors of my accent WLED lights. It has served as a really great source of dynamic colors, and keeps things fresh.
I've spent a good bit of time tweaking this for my use-case, and one of the things I had to implement was a way to make sure the colors that I set the lights to weren't too similar. Most album art has a handful of colors, but I found that often, it would identify very similar colors as the most prominent ones, which doesn't make for a great multi-color palette.
I've played around with this integration a bit, and it seems to me like it's more meant for use-cases where you're grabbing a single color from the palette returned by get_image_vibrant_colors
. Please correct me if I'm wrong, but that's the vibe I got.
Describe the solution you'd like
It would be nice if this integration had a way to get multiple prominent colors that aren't too similar, as I'm doing in my use-case. The implementation I landed on is as follows:
- Get the top 20 prominent colors using the
get-image-colors
library - Calc brightness for each (
r + g + b
, 0-765), and filter out any colors not within the range of 200-600 (dark colors don't pop on the lights, and whites aren't fun)
Note: I totally acknowledge that this is a weird way to do this, but I found that using the (L)ightness from HSL didn't do as good a job of representing the perceived brightness of these colors. I'm sure there's a better way, but I'm not super well-versed in color theory, and this implementation is a super simple, and has worked great. - Find hues for each in the HSL colorspace (0-360), and remove any that are within
20
of another color. This is the most important piece of this imo - Set the lights to a pattern using the top 3 colors left after filtering (this had to be done through the WLED API and was a headache of its own, but not within scope of this)
I've found this to do a great job of grabbing colors that look great, and stand out.
That all said, it would be great if SpotifyPlus had a way to do something similar. That said, the existing implementation of this service returns a well-defined palette, as opposed to my more arbitrary list of colors.
As such, I think the cleanest way to implement this would be to add a few more optional parameters:
- brightness min
- brightness max
- hue separation (degrees in HSL colorspace)
If unset, these would not change the existing behavior.
The brightness range would be used to filter all the colors in the palette, and the hue separation could be used to either filter all the colors returned, or just colors within each of the 3 groups (dark, light, general).
Describe alternatives you've considered
Just doing a bit of poking around, it seems like using relative luminance or the L* component of the CIELab colorspace would be a more standard approach that may yield better results.
I'm absolutely open to feedback on how this functionality might fit in best to the existing implementation. I'd love to switch my setup over to this library to avoid my NodeRED spaghetti :)