Closed Heldaeus closed 4 months ago
Describe the solution you'd like I propose splitting lbm/dbm into two options. Saturation and brightness. Below is the same screenshot as above with the UI selectively de-saturated via the hue/saturation adjustment in Photopea.
If you measure the difference between the two you'll see that reducing the saturation in Photopea lowers or raises each color channel towards the average value between them all opposed to how this script seems to function by raising all channels towards white or black depending on if the theme is light or dark. If the user could choose their desired saturation level with lbm/dbm then choose a brightness level on a 0-4 scale per light and dark theme that would solve the issue of overly saturated themes. Additionally this would help when generating decent grey themes.
Describe alternatives you've considered Using a lower factor of multiplication for lbm and dbm, while it does reduce the saturation of the seeded colors, does not offer dexterity over the brightness of the theme. I'm unable to achieve de-saturated middle toned themes, only saturated ones. I've attempted to use alternative colors with inherently less saturation and brightness for the seed but the script seems to favor hue and ignore sat/brightness in most cases.
As is now this program gets the material you color schemes from the python port of material-color-utilities, as stated in the readme, by default those colors are what is best optimized for interface colors keeping (visibility, readability and accessibility).
I decided to blend the background color against the primary color [40] dark, [70] light of the tonal palette, so themes didn't look too white/black, but other colors are still taken exactly like M3 scheme provides (accent, text), that's why it's limited.
Since changing the background too much would require adjusting everything and I didn't really want to deep dive in color science things, which would require me time to understand how to apply them well, I decided to keep things simple.
But I really like the concept of allowing to customize how colors should look, similarly to the Dynamic Themes that android has where you can choose between different variants and it's now available in the java library (which needs to be ported to the python and I haven't looked on how big other needed changes are)
Also, I'm still a novice, this is my very first python project of this kind so I'm still learning. So probably will look into that but might be a very long term goal depending on how hard it turns out to implement.
Perhaps a more convenient solution is to implement a saturation filter after the colors have been generated?
I don't know if that would be more accessible but it would likely suffice.
Hmm, probably that could work
original:
1.5 saturation
0.5 saturation
light version for comparison:
Edit: last screenshots were taken with 4.0 blend factor, changed to correct one (1.5 factor, same as dark version above)
This looks promising. Even the 1.5x saturation doesn't look bad. I'm very interested in testing.
Please test the https://github.com/luisbocanegra/kde-material-you-colors/tree/saturation-and-brightness branch :)
Apart of the current blend options:
# The amount of perceptible color for backgrounds in light mode
# A number between 0 and 4.0 (limited for accessibility purposes)
# Defaults to 1 if not set
light_blend_multiplier = 1
# The amount of perceptible color for backgrounds in dark mode
# A number between 0 and 4.0 (limited for accessibility purposes)
# Defaults to 1 if not set
dark_blend_multiplier = 1
It now has these controls:
# The saturation of colors in light mode
# A number between TODO: set limits
# Defaults to 1 if not set
light_saturation_multiplier = 1
# The saturation of colors in dark mode
# A number between TODO: set limits
# Defaults to 1 if not set
dark_saturation_multiplier = 1
# The brightness of colors in light mode
# A number between TODO: set limits
# Defaults to 1 if not set
light_brightness_multiplier = 1
# The brightness of colors in dark mode
# A number between TODO: set limits
# Defaults to 1 if not set
dark_brightness_multiplier = 1
Note: There are no limits for those new values yet, so hangs are expected
These controls change konsole/pywal appearance too, but probably it will better for these to have its own control so they each color can still be distinguishable on very high saturation
❤️
Before:
After:
I think the blue color was sampled from the shadows in the wallpaper but that color clearly isn't representative of the image. Like at all. But, with the saturation at 0.25x it fits the vibe better. I probably went too far with .25x though.
I need to play around with these settings more, but so far the sat options are awesome.
B/W or grayish images tend to return a default color, ~Pixel~ Google blue, the algorithm in material-color-utilities discards the colors that aren't very suitable for generating themes, that could probably be changed but never looked into that.
One thing I'm noticing is that colors look too bright when they're de-saturated. They don't share the same perceptual lightness as the saturated version. It's just bugging me. I figure that maybe a solution can be sought from the Munsell color system but I at that point you'd be delving into colorimetry which I know you're trying to tread lightly on. But, heres a graph anyways.
I did some playing around with comparing the grey/color that the script produces vs Munsell and the Munsell color relationships I felt looked better and made more sense.
I'm not entirely sold on the brightness setting when it comes to darkening the colors. It's too reminiscent of camera exposure for me, like it's compressing the foreground colors too much and they blend into the background. Lightening the colors seems fine though. I actually think the setting may be redundant since the color multiplier settings kind of achieve the same effect already.
Regarding dbm/lbm I've realized that the ratio of brightness between the 'view background' color and the 'window background' color in the 4x seed is larger than in the 1x.
Example:
Vs what would be more consistent in my opinion.
This is kind of a nit pick though and not super important.
One thing I'm noticing is that colors look too bright when they're de-saturated. They don't share the same perceptual lightness as the saturated version. It's just bugging me. I figure that maybe a solution can be sought from the Munsell color system but I at that point you'd be delving into colorimetry which I know you're trying to tread lightly on. But, heres a graph anyways.
I did some playing around with comparing the grey/color that the script produces vs Munsell and the Munsell color relationships I felt looked better and made more sense.
I'm not entirely sold on the brightness setting when it comes to darkening the colors. It's too reminiscent of camera exposure for me, like it's compressing the foreground colors too much and they blend into the background. Lightening the colors seems fine though. I actually think the setting may be redundant since the color multiplier settings kind of achieve the same effect already.
Yeah, it's the problem of using the HSV color model (maybe HSL would've been better?), the right thing would be to use what material-color-utilitie uses, HCT I want to do that at some point.
Regarding dbm/lbm I've realized that the ratio of brightness between the 'view background' color and the 'window background' color in the 4x seed is larger than in the 1x.
Example:
Vs what would be more consistent in my opinion.
This is kind of a nit pick though and not super important.
Probably, window background was changed no long ago to match chromeos early Material You, that's why it looks too different
I think I'll open a new issue for people to propose/help making changes in the default colors according to m3 guidelines 👍
Tried to experiment with HCT by directly multiplying the chroma (saturation/colorfulness) on the generated palettes and here are the results.
How does it look? I want to replace blend multiplier with it and then try to implement lightness (tone) control
Different hue
I think this may be ready, thoughts?
Is your feature request related to a problem? Please describe. The lbmultiplier and dbmultiplier options are great for creating themes with different levels of contrast between the background and foreground/text colors but often times when using a high factor of multiplication, especially with the light variant of a theme, the background saturation is too potent. There is no apparent option to ameliorate this whilst retaining a low contrast visual effect.
Here is an example of an appealing low contrast dark theme. (At least for me.)
Now a low contrast light variant. (At least for me this far too bright.)
Describe the solution you'd like I propose splitting lbm/dbm into two options. Saturation and brightness. Below is the same screenshot as above with the UI selectively de-saturated via the hue/saturation adjustment in Photopea.
If you measure the difference between the two you'll see that reducing the saturation in Photopea lowers or raises each color channel towards the average value between them all opposed to how this script seems to function by raising all channels towards white or black depending on if the theme is light or dark. If the user could choose their desired saturation level with lbm/dbm then choose a brightness level on a 0-4 scale per light and dark theme that would solve the issue of overly saturated themes. Additionally this would help when generating decent grey themes.
Describe alternatives you've considered Using a lower factor of multiplication for lbm and dbm, while it does reduce the saturation of the seeded colors, does not offer dexterity over the brightness of the theme. I'm unable to achieve de-saturated middle toned themes, only saturated ones. I've attempted to use alternative colors with inherently less saturation and brightness for the seed but the script seems to favor hue and ignore sat/brightness in most cases.