[Feature Request] image editor feature

[LovingMelody]

Proposal: Image Editor Feature for Stylix

I would like to see the addition of an image editor feature for Stylix, allowing users to edit the final image which would then be used by Stylix after palette generation.

Proposed design

options.stylix = {
    imageEditor = {
      enable = lib.mkOption {
        type = lib.types.bool;
        default = false;
        description = ''
          Update Wallpaper by applying a lut filter to the image
        '';
      };
      method = lib.mkOption {
        type = with lib.types; functionTo (coercedTo package toString path);
        default = i: i;
        description = ''
          A function to edit the image, takes one argument (the image)
          and returns the resulting edited image
        '';
        example = ''
          config.stylix.imageEditor.method = with config.lib.stylix.imageEditors;
            img: upscaleImage "2x" (applyLut img)
        '';
      };
    };
};

This design allows for a gneric method for image editing, which would then be utilized by Stylix. I believe this method should run after palette generation to allow the palette to be applied to the image if desired. This would also allow to use their own method to edit images including up-scaling or methods that we could define within the flake which could be chained together.

To ensure that the user's images are not edited unexpectedly after an update this feature should be opt-in and the default method be some method of applying colors to the image (ex: lutgen). An alternative design wold be to simply define the image editor option to be a function which defaults to a no-op (i: i).

Related Issues:

Issue #469 proposes adding the ability to recolor the wallpaper using a tool like PaletteNet when both a wallpaper and a color scheme are supplied. This option should be opt-out.

[LovingMelody]

I am willing to submit a PR implementing this feature to implement this, my fork currently implements this though I'm not entirely happy with the behavior. To use the edited image with the current implementation I have, you would need to reference config.stylix.generated.image

[trueNAHO]

I would like to see the addition of an image editor feature for Stylix, allowing users to edit the final image which would then be used by Stylix after palette generation.

This design allows for a gneric method for image editing, which would then be utilized by Stylix.

If I understood correctly, Stylix should provide generic capabilities to modify the ultimately displayed stylix.image. How this functionality integrates with #63 is still an open question.

IMHO, generic image modification exceeds Stylix's purpose of uniformly theming applications. Unlike image modifications based on Stylix parameters like the palette (#469), generic image modifications should be left to the end-user. After all, Stylix cannot possibly support every imaginable image modification feature request. @danth, what do you think?

To ensure that the user's images are not edited unexpectedly after an update this feature should be opt-in and the default method be some method of applying colors to the image (ex: lutgen). An alternative design wold be to simply define the image editor option to be a function which defaults to a no-op (i: i).

Modifying images at Nix build time stores them in the Nix store. With #63, this results in potentially unbounded duplicate data.

I believe this method should run after palette generation to allow the palette to be applied to the image if desired.

Modifying the image based on the palette only makes sense when the palette is not generated based on the image.

This would also allow to use their own method to edit images including up-scaling or methods that we could define within the flake which could be chained together.

Do you mean by "define within the flake" that Stylix should expose functions through lib?

I am willing to submit a PR implementing this feature to implement this, my fork currently implements this though I'm not entirely happy with the behavior. To use the edited image with the current implementation I have, you would need to reference config.stylix.generated.image

IMHO, unless you have a lot of free time, it is overall less work to reach a consensus before implementing such a large feature.

[LovingMelody]

If I understood correctly, Stylix should provide generic capabilities to modify the ultimately displayed stylix.image. How this functionality integrates with #63 is still an open question.

IMHO, generic image modification exceeds Stylix's purpose of uniformly theming applications. Unlike image modifications based on Stylix parameters like the palette (#469), generic image modifications should be left to the end-user. After all, Stylix cannot possibly support every imaginable image modification feature request. @danth, what do you think?

The main motive for creating a generic method is to allow different methods of editing a palette.

Modifying the image based on the palette only makes sense when the palette is not generated based on the image.

Yes and no, depends on the image & personal preference as the result is not the same image though similar
Here is a result from lutgen:
Though, dropping this would greatly reduce complexity as this could be a simple apply function on the option.

Edit: Maybe not, I have no easy way of knowing if its using a generated palette.

Do you mean by "define within the flake" that Stylix should expose functions through lib?

yes

IMHO, unless you have a lot of free time, it is overall less work to reach a consensus before implementing such a large feature.

Truthfully, this feature took me all of maybe ~10min to implement in its current state as a lot of this is something I already use in my flake

[trueNAHO]

If I understood correctly, Stylix should provide generic capabilities to modify the ultimately displayed stylix.image. How this functionality integrates with #63 is still an open question.

IMHO, generic image modification exceeds Stylix's purpose of uniformly theming applications. Unlike image modifications based on Stylix parameters like the palette (#469), generic image modifications should be left to the end-user. After all, Stylix cannot possibly support every imaginable image modification feature request. @danth, what do you think?

The main motive for creating a generic method is to allow different methods of editing a palette.

Alright, now I understand. Disregarding #63 and the palette extension roadmap, this implementation seems fine for now.

I am willing to submit a PR implementing this feature to implement this, my fork currently implements this though I'm not entirely happy with the behavior. To use the edited image with the current implementation I have, you would need to reference config.stylix.generated.image

Could you submit your fork as a PR to simplify the feedback loop?

Could you also revert formatting related modifications to simplify the diff? In the future, #236 should resolve such issues.