"Levels" filter layer can be created and added to the stack using the Python API but setting its properties programmatically has no effect on the filter layer. Setting properties on other filter layers works fine. This may be a case where it's just not implemented in the API yet, but regardless it's a roadblock for me. For example, I can add the filter layer manually and try to affect it through Scripter by entering something like: Krita.instance().activeDocument().activeNode().filter().configuration().setProperty('gammavalue', 0.452) Krita.instance().activeDocument().refreshProjection() I can query that value with: print(Krita.instance().activeDocument().activeNode().filter().configuration().properties()) This will spit out something like {'gammavalue': 0.452} plus any other property I've tried to set, but none of that has any effect on the filter layer itself. I'm able to do similar operations with other filter layers just fine. The reason I would need to do this is that I'm writing a plugin for working with normal maps, and it's better to be able to work in 16-bit and only export to 8-bit if need be. Other than missing proper dithering (which I'm faking), this is fairly possible by setting a few properties in the png exporter (namely Embed sRGB profile, Force convert to sRGB, and Force convert to 8 bits/channel), but the color representation will obviously be off from 16-bit > 8-bit, so the simplest way to fix that beforehand is to add a Levels filter layer at the top of the stack and change the gamma value to 0.452. It's not a great experience to ask a user of my plugin to change that value manually on every project, so ideally that would be taken care of by the plugin. Aaaand I just realized I could start up a project with the gamma corrected sRGB-elle-V2-srgbtrc profile instead...hmmm...which might work...but then becomes a problem if I actually want to export in 16-bit linear...so the problem remains. Even just being able to set the "mode" to "channels" and change "gammavalue" would solve my issue with the Levels filter layer at the moment. Krita Version: 5.2.0-prealpha (git 508d078) [and previous versions] Hidpi: false Qt Version (compiled): 5.15.7 Version (loaded): 5.15.7 OS Information Build ABI: x86_64-little_endian-lp64 Build CPU: x86_64 CPU: x86_64 Kernel Type: linux Kernel Version: 6.4.2-3-MANJARO Pretty Productname: Manjaro Linux Product Type: manjaro Product Version: unknown Desktop: XFCE Appimage build: Yes
A possibly relevant merge request was started @ https://invent.kde.org/graphics/krita/-/merge_requests/1858
Hi varkatope, I made a merge request that tries to handle this. I have to say that similar issue happens also on other filters... but I only fixed this one for now. Please try the changes by downloading the linux artifact for the mr (https://invent.kde.org/graphics/krita/-/jobs/1065247/artifacts/download) and let me know if it solves the issue. When I improved the levels filter I also changed the properties to better include the new ones. This is the structure in xml form: * levels curve param follows this format: "input_black_point;input_white_point;input_gamma;output_black_point;output_white_point" A string with the 5 values. The input/output black/white points have a [0, 1] range, not [0, 255]. * For backwards compatibility, the "blackvalue" etc. values are also saved. Those contain the same values as the lightness mode levels. * The new xml form is: <params version=2> <param name="mode">lightness</param> <param name="histogram_mode">logarithmic</param> <param name="lightness">0;1;0.4;0;1</param> <param name="number_of_channels">3</param> <param name="channel_0">0;1;1;0;1</param> <param name="channel_1">0.2;0.8;1.2;0.25;0.75</param> <param name="channel_2">0;1;0.6;0;1</param> <param type="internal" name="blackvalue">0</param> <param type="internal" name="whitevalue">255</param> <param type="internal" name="gammavalue">1</param> <param type="internal" name="outblackvalue">0</param> <param type="internal" name="outwhitevalue">255</param> </params> * "number_of_channels" and "channel_*" change depending on the color space used and start at 0. "mode" can be "lightness" or "channels". "histogram_mode" can be "linear" or "logarithmic", although that is used for the gui only. * You can set the properties from python as you did in your first message now using the same property names and values as the xml. You can set the whole levels for the lightness mode for example with `setProperty("lightness", "0;1;0.5;0;1")` or similar. * For the the old values ("blackvalue", etc.) are also stored. If you change one of thes then the "lightness" option is also changed. Conversely, if you change the "lightness" option then the old values are also changed.
(In reply to Deif Lou from comment #2) Hello Deif. That's brilliant! Thanks for such a quick fix. I wasn't expecting that but certainly do appreciate your work. I was able to set all the properties as you laid out, including the legacy ones (blackvalue, etc.), so this certainly fixes the issue on my end. I did encounter a few errors (see below) when starting my plugin with your build, which doesn't happen with the nightly I was using. The plugin creates a bunch of layers, filters, and filter layers and I encountered the same error three times during that process. Of course, this may be an "in development" situation elsewhere in the build. Reporting it here anyway, just in case. I was able to ignore them regardless. Cheers! ****** Krita has encountered an internal error: SAFE ASSERT (krita): "dummy" in file /builds/graphics/krita/libs/ui/flake/kis_dummies_facade_base.cpp, line 120 Please report a bug to developers! Error: Press Ignore to try to continue. Press Abort to see developers information (all unsaved data will be lost) ******
Hi. Can you tell when this happens? For some specific type of layer or the like? I think that may be some unrelated bug to this and may need another bug report.
Git commit 929d259bd4696002b32fad0d1e00f7e1848a85e7 by Deif Lou. Committed on 19/07/2023 at 17:23. Pushed by merge-service into branch 'master'. Fix handling of configuration properties on levels filter Part-of: <https://invent.kde.org/graphics/krita/-/merge_requests/1858> M +18 -3 libs/image/KisLevelsCurve.cpp M +5 -0 libs/image/KisLevelsCurve.h M +146 -63 plugins/filters/levelfilter/KisLevelsFilterConfiguration.cpp M +12 -10 plugins/filters/levelfilter/KisLevelsFilterConfiguration.h https://invent.kde.org/graphics/krita/-/commit/929d259bd4696002b32fad0d1e00f7e1848a85e7
(In reply to Deif Lou from comment #4) > Hi. Can you tell when this happens? For some specific type of layer or the > like? I think that may be some unrelated bug to this and may need another > bug report. Hi again. Unfortunately I can`t really tell at what point I`m getting that error in your build. If I just start a new project and start adding layers, filers, etc. I can`t recreate it. Only when my plugin adds a bunch of stuff in quick succession, makes groups, locks layers, selects stuff by name... I don`t know. The new nightly (529349f) seems to work fine for me and I thiiiink that includes changes to "flake" specifically as in here: https://binary-factory.kde.org/job/Krita_Nightly_Appimage_Build/2072/changes Here are a few logs but not sure they`re super helpful. Let me know if you think I should do a separate bug report on this, though. Thanks. Your build: SESSION: 19 Jul 2023 14:48:16 -0400. Executing /tmp/.mount_krita-mmfdXP/usr/bin/krita Krita Version: 5.2.0-prealpha (git f742174), Qt version compiled: 5.15.7, loaded: 5.15.7. Process ID: 33666 -- -- -- -- -- -- -- -- 19 Jul 2023 14:48:16 -0400: Style: fusion. Available styles: Windows, Fusion 19 Jul 2023 14:48:18 -0400: Database is up to date. Version: 0.0.17, created by Krita 5.1.0, at Wed. Sep. 7 22:50:11 2022 19 Jul 2023 14:48:18 -0400: Could not load resource layerstyles/normals_tools_library.asl 19 Jul 2023 14:48:18 -0400: Could not load resource layerstyles/normals.tag 19 Jul 2023 14:48:18 -0400: Could not load resource layerstyles/small_recessed_grille.asl 19 Jul 2023 14:48:24 -0400: KisAppimageUpdater: update check finished. Result: 2 Exit status: 0 path: /home/myname/Desktop/Krita_levels/krita-5.2.0-prealpha-f742174ed7-x86_64.appimage output: 19 Jul 2023 14:48:31 -0400: Created image "Project Name", 1024 * 1024 pixels, 300 dpi. Color model: 16-bit integer/channel RGB/Alpha (sRGB-elle-V2-srgbtrc.icc). Layers: 1 19 Jul 2023 14:48:33 -0400: SAFE ASSERT (krita): "dummy" in file /builds/graphics/krita/libs/ui/flake/kis_dummies_facade_base.cpp, line 120 KRITA DID NOT CLOSE CORRECTLY ================================================================================ The new nightly (which doesn`t include your changes yet): ================================================================================ SESSION: 19 Jul 2023 15:07:30 -0400. Executing /tmp/.mount_krita-eAhhMB/usr/bin/krita Krita Version: 5.2.0-prealpha (git 529349f), Qt version compiled: 5.15.7, loaded: 5.15.7. Process ID: 34157 -- -- -- -- -- -- -- -- 19 Jul 2023 15:07:30 -0400: Style: fusion. Available styles: Windows, Fusion 19 Jul 2023 15:07:32 -0400: Database is up to date. Version: 0.0.17, created by Krita 5.1.0, at Wed. Sep. 7 22:50:11 2022 19 Jul 2023 15:07:32 -0400: Could not load resource layerstyles/normals_tools_library.asl 19 Jul 2023 15:07:32 -0400: Could not load resource layerstyles/normals.tag 19 Jul 2023 15:07:32 -0400: Could not load resource layerstyles/small_recessed_grille.asl 19 Jul 2023 15:07:37 -0400: KisAppimageUpdater: update check finished. Result: 0 Exit status: 0 path: /home/myname/Downloads/krita-5.2.0-prealpha-529349f772-x86_64.appimage output: 19 Jul 2023 15:07:45 -0400: Created image "Project Name", 1024 * 1024 pixels, 300 dpi. Color model: 16-bit integer/channel RGB/Alpha (sRGB-elle-V2-srgbtrc.icc). Layers: 1 19 Jul 2023 15:07:46 -0400: SAFE ASSERT (krita): "dummy" in file /home/appimage/workspace/Krita_Nightly_Appimage_Build/krita/libs/ui/flake/kis_dummies_facade_base.cpp, line 120 19 Jul 2023 15:07:46 -0400: SAFE ASSERT (krita): "dummy" in file /home/appimage/workspace/Krita_Nightly_Appimage_Build/krita/libs/ui/flake/kis_dummies_facade_base.cpp, line 120
If you have the crash in the nightly that will have my changes then it will need a new bug report, but it will have to provide the steps to reproduce the issue and maybe the script you use (or a simplified version that also provokes the crash) to debug. The safe asserts appear also in the nightly that doesn't have my changes so the issue may be other.
(In reply to Deif Lou from comment #7) > If you have the crash in the nightly that will have my changes then it will > need a new bug report, but it will have to provide the steps to reproduce > the issue and maybe the script you use (or a simplified version that also > provokes the crash) to debug. The safe asserts appear also in the nightly > that doesn't have my changes so the issue may be other. Alright, I'll see if it crops up in the next build with your changes. Thanks.