Bichromatic color scheme

[DavidLokison]

In addition to the color schemes, it would be awesome if we also had options for selecting which colors get selected into the palettes in the first place. There has been quite some interest in that feature over on the Discord and I am pulling up a tracking and discussion issue here so we can gather ideas and possible implementations here in a searchable manner.

[frvgmxntx]

It would be awesome if we also had options for selecting which colors get selected into the palettes in the first place.

that’s actually kind of already how it works since MD3 generates the full palette from a base color, and Matugen already lets you choose that base color.

what I've been thinking was to add specific index arguments for each MD3 tonal palette:
--primary-color-index (overrides for the primary palette)
--secondary-color-index (same as above for the secondary)
--tertiary-color-index (same as above for the tertiary)
--neutral-color-index (surface, background, etc.)
--neutral-variant-color-index (surface-variant, etc.)
--error-color-index

another approach that could work for those “dual color” or monochromatic wallpapers, could be introducing a new scheme variant (e.g. SchemeBichromatic, SchemeTwoTone).

the idea would be to extract the top two distinct colors from the image, one from the accent and one from the background. Then it should derive the Primary and Secondary from the dominant (accent) color, and the Tertiary and Neutral (surface/background) from the second color (background).

this might give more predictable results for images that don’t have a lot of color variety.

[XurxoMF]

the idea would be to extract the top two distinct colors from the image, one from the accent and one from the background. Then it should derive the Primary and Secondary from the dominant (accent) color, and the Tertiary and Neutral (surface/background) from the second color (background).

That sound reeeally nice. Could be a reeally good option.

My idea was adding a way so users can fully customize the color palette generated using a JSON, TOML or whatever. Example:

1. Metugen extracts a few palettes like it does now but with 2-3 colors instead of 1. 4 sets of 2-3 colors colors to choose from.
2. With the set you selected it'll extract the 3 colors and call them primary_source, secondary_source and tertiary_source.
3. Then, using the JSON, TOML... users can modify those colors in different ways so to create a new pallete. Right now we have colors. and base16. Now there would be a third one called user. or custom. ...

Fast idea:

1. Generate a color called background (used like custom.background.default.hex for example)
2. Use primary_source as base color
3. If it's dark theme mix 90% black with 10% of the base color (primary_source in this case), if it's light theme do the same with white instead of black
4. Optionally tweak light, saturation... with some presets like to_monochrome, saturation 0.0-1.0, brightness 0.0-1.0...

Another color:

1. Generate a color called on_background (used like custom.on_background.default.hex for example)
2. Use primary_source as base color
3. If it's dark theme mix 95% white with 5% of the base color (primary_source in this case), if it's light theme do the same with black instead of white
4. Optionally tweak light, saturation... with some presets like to_monochrome, saturation 0.0-1.0, brightness 0.0-1.0...

This way users can do whataver they want with the source colors. More bright colors, monochrome... whatever...
Then they can use those generated colors like we do now, with {{ custom.name.defaukt.hex }} for example.
This is the idea, there are a lot of ways to implement this with code so... I don't know how you've Matugen coded, what you can or can't do, what Rust allow us to do or not... I've just studied Rust but never used before so...

[DavidLokison]

First of all: great ideas! Especially the index variant seems plausible to do, we basically just have to introduce a bunch of new schemes with a similar structure like in the base material_colors library. SchemeBichrome seems like a good choice of a name following the naming convention of the lib. As for the fully custom scheme: SchemeIndexed transfers what is going on in the background.

I am still undecided letting the user select the error source color though... Since every scheme in the library uses the same hard coded error color, I don't know what's the reasoning behind that. If we now introduce a bunch of schemes that feature a different error color we break the "principle of least surprise", but on the other hand I personally find the default error color pretty ugly and would want a way to change it. Maybe we skip the error color index for now, but think about a way to change it "globally" for all schemes.

As to color selection: we already have two different backends for MD3 and Base16 color extraction. Both ImageReader and WalBackend would theoretically allow selecting more distinct colors and also (maybe) selecting colors using a set of rules (like "saturation about 0.4 to 0.6"). Streamlining the two of them into one global "backend" setting will be a whole different issue probably but we kinda need to refactor that either way.

So, if you want to implement a SchemeBichrome, go for it. The other topics would probably need more work.