Inconsistent Color Mapping and Proposal for Custom Color Replacement

[m0r4a]

Description

I have this problem/nitpick/thingy with the color generation, the "inconsistency" of colors when processing images. For instance:

• In one image, colors 1, 3, and 5 might form a gradient based on the primary color.
• In another image, these same colors could be completely unrelated.

I get that this is just how pywal works, but I’ve been thinking about a way to handle this with custom color replacements for specific images.

Possible solutions

1. External Script:

• Write a separate script that replaces colors in the files after they’re generated.
• This works but feels a bit messy.
• It's less than ideal bout would not have to commit to the repository directly or if I do a fork, maintain the project.

2. Built-in Replacement Feature:

• Add a function that reads a config file (maybe JSON) and replaces colors during the export process.

Example of the JSON:

{
  "wallpaper1": {
    "color1": "color5",
    "color4": "color9",
    "color2": "color6"
  },
  "wallpaper2": {
    "color4": "color3"
  }
}

Questions

• Would this fit with the project’s goals?
• Should the replacement logic happen during export or somewhere else?

Let me know what you think about this idea.

[m0r4a]

Now that I think about it, you could just create themes, tweak them, and use those instead of making a function to replace colors. This project is really well thought out lol.

I guess I'll wait for some feedback before closing the issue, but I think that could be a really good alternative.

[eylles]

I have this problem/nitpick/thingy with the color generation, the "inconsistency" of colors when processing images. For instance:

• In one image, colors 1, 3, and 5 might form a gradient based on the primary color.
• In another image, these same colors could be completely unrelated.

I get that this is just how pywal works, but I’ve been thinking about a way to handle this with custom color replacements for specific images.

ah the color mapping, really pywal colorschemes are more geared to have a pseudo grayscale contrast, the colors that tend to contrast and be accent and secondary accent are background, foreground, 0, 15 (color 0 and background aren't always the same tho) color 4 (and 12) (accent) color 2 (and 10) secondary accent.

those are the more or less guaranteed-ish color combinations that will be different enough, that is how dylan built pywal and in pywal16 that doesn't change only that we can get the additional color shades.

Now that I think about it, you could just create themes, tweak them, and use those instead of making a function to replace colors.

yeh that can be done if you want

This project is really well thought out lol.

i'll be honest not very often i read, hear or even think that about pywal.

[CarterSnich]

Same here. It would be cool if you can re-arrange the generated theme. This is what I got with my wallpaper of choice:

I have colors that almost had the same shade, and only 3 or 4 that completely contrasts.

I tried using different backends, and they generated better results. But, the color arrangement doesn't match the context of usage. Like, the prompt is more colored red, and my error and warning texts are more blue.

[eylles]

yeh pywal wasn't really designed for keeping the semantic meaning of colors, is more of a looking pretty than being functional in that regard (tho that is a core fundament of ricing that some functionality may be hampered in favour of aesthetics)

i personally have forgotten what the semantic meanings of colors were even supposed to mean...

i'm just used to seeing things as colorful greyscale and relying on the actual error messages and warning symbols instead of on specific colors, tho i know there are some efforts to try and add color semantization to pywal and i would not be opposed to eventually merging that to pywal16 but not as the default behaviour but rather an option as not even the generation of 16 shades of colors is the default on pywal16 even now that the current master can generate the 16 shades for the old built in themes that were just 9 colors (colors 1 to 7 were the same as colors 9 to 15)

[eylles]

anyway, just to mention i've been thinking of ways to achieve color semantization, well sort of, it woldn't be a default but rather a new flag like the --cols16 flag, what i've been thinking is 2 approaches to semantizing the colors.

1. try to map the colors generated by pywal to the ansi semantic meanings as it can be, like murtaza64's fork does.
2. symmetric color generation, this would be to take the accent (and maybe the secondary accent color) to generate the colors geometrically, first pinning the hue of the accent color to the closes ansi color hue, set it as that ansi meaning and from there rotate the hues to obtain the 6 unique ansi hues.

both approaches would have to be called from the generic adjust function and take place before the adjusting to create the secondary shades by either lightening or darkening of the colors.

tho this would be a milestone for either pywal16 3.9.0 or maybe even 3.10.0