batch_export plugin: Allow specifying an export color profile

Adds a new metadata tag, icc, that allows you to select an icc color profile to convert to when exporting.

This is useful if, for example, you are maintaining a normal map (usually stored as a linear image) and a color texture (usually stored with gamma) for a 3d model in the same krita document, so that you can use clone layers and filters to ensure that certain features are replicated across multiple textures automatically.

Test Plan

  1. Enable the "Batch Exporter" plugin
  2. Create 3 layers with content, named default e=png, inherit e=png, and custom e=png icc=sRGB-elle-V2-g10.icc
  3. Create a group for the inherit layer, named group icc=sRGB-elle-V2-g10.icc
  4. Show the "Batch Exporter" docker.
  5. Click the "All Layers" button under the "Export" heading in the "Batch Exporter" Docker.
  6. The exported files should be:
  • default.png: exported w/ the srgbtrc color profile
  • custom.png: exported w/ a linear color profile
  • inherit.png: also exported w/ a linear color profile

Additional Information

Don't use fill layers when testing this feature, they seem to be ignored when performing a batch export? I believe this is a pre-existing bug that I don't have the energy to try and track down at the moment. I'm observing this behavior using a source document w/ 16 bit depth, linear color.

Formalities Checklist

  • I confirmed this builds.
  • I confirmed Krita ran and the relevant functions work.
  • I tested the relevant unit tests and can confirm they are not broken. (If not possible, don't hesitate to ask for help!)
    • I did not see any unit tests for this plugin. If I missed them, please let me know so I can run them.
  • I made sure my commits build individually and have good descriptions as per KDE guidelines.
  • I made sure my code conforms to the standards set in the HACKING file.
    • While there are pep8 failures in this file, I don't believe I have added any of my own.
  • I can confirm the code is licensed and attributed appropriately, and that unattributed code is mine, as per KDE Licensing Policy.
  • Does the patch add a user-visible feature? If yes, is there a documentation MR ready for it at Krita Documentation Repository?
    • This patch adds a user-visible plugin feature, and documentation has been added to the plugin's manual.
    • The plugin's Manual.html was re-generated from the Manual.md using the following command: pandoc -f markdown --wrap=none -t html5 Manual.md -o Manual.html
      • Is there a good place to document this? Maybe as a comment in the markdown file?
      • Reading pull request history, I don't appear to have been the first person to have initially been confused.

Reminder: the reviewer is responsible for merging the patch, this is to ensure at the least two people can build the patch. In case a patch breaks the build, both the author and the reviewer should be contacted to fix the build. If this is not possible, the commits shall be reverted, and a notification with the reasoning and any relevant logs shall be sent to the mailing list, kimageshop@kde.org.

Merge request reports

Loading