[Feature Request] Recolor wallpaper when possible

[Mikilio]

Right now when supplying a wallpaper the colorscheme gets generated by a genetic algorithm. When a colorscheme is also supplied it is chosen instead. I would like to add the possibility to recolor the wallpaper using a tool like PaletteNet when both are supplied. This option to enable this should be opt-out.

I wanted to work on this for myself. When it's done I would need some help integrating it into stylix because it's quite a big repo and I don't know where to change stuff.

[trueNAHO]

Potentially related:

The options.stylix.targets.<TARGET>.wallpaper options would be <TARGET> specific, similar to options.stylix.targets.<TARGET>.enable.

Based on the following use cases, it makes sense to add a stylix.enableWallpaper option complementary to stylix.autoEnable:

• Get color scheme from stylix.image without setting stylix.image as wallpaper: stylix = { enableWallpaper = false; image = image; }.
• Get color scheme from stylix.image and set stylix.image as wallpaper: stylix = { enableWallpaper = true; image = image; }.
• Manually declare color scheme (stylix.base16Scheme) and entirely ignore stylix.image: stylix = { base16Scheme = base16Scheme; enableWallpaper = false; image = null; }.

For reference, it has been considered to better rename the stylix.autoEnable option. Additionally, these use cases somewhat correspond to the slideshow feature suggestion.

-- #442 (comment)

[LovingMelody]

This previously was possible to be done by the user as notated in Tips & tricks however as I've reported in #437 this is no longer working. This would likely close that issue in the process

[Mikilio]

This is not quite what I was referring to. I hoped to have a supported default smart recoloring mechanism. And I from what I was able to try, PaletteNet offered the best results. (Definitely better than lutgen).

[LovingMelody]

Example code in the issue just happens to be what I use, there's no real reason why it couldn't be substituted for pretty much anything else. The issue occurred from the color palette being referenced but for some reason stylix is still attempting to reference one generated from the image.

PS: Looks like PaletteNet doesn't include a license, which should be addressed before an implementation of it is added.

[Mikilio]

Example code in the issue just happens to be what I use, there's no real reason why it couldn't be substituted for pretty much anything else. The issue occurred from the color palette being referenced but for some reason stylix is still attempting to reference one generated from the image.

To be honest, I'm a bit confused what you mean because all is working well on my side regarding this.

I actually already have a configuration that works for this locally. I'm just not happy with the result yet.
That is why I was thinking that retraining the model for base16/base24 colors would be nice. (reading the paper, there is no reason why this would not work)

[trueNAHO]

PS: Looks like PaletteNet doesn't include a license, which should be addressed before an implementation of it is added.

Indeed.

That is why I was thinking that retraining the model for base16/base24 colors would be nice. (reading the paper, there is no reason why this would not work)

AFAIK, the current color scheme roadmap is to extend it to VIM highlight groups, although base24 support can be implemented in the meantime.

In the future, #63 implies image and video sources to be modified at run time. With that in mind, we should reconsider installing pre-trained models. Maybe we could introduce an option whether images and videos should be modified with a pre-trained model or modified procedurally with a potentially less accurate algorithm.

[Mikilio]

#473 seems like a good general design for the feature I'm looking for. As such, I will close this issue and defer to that. Should I ever make progress on my front, I'll mention it there.