Created attachment 147882 [details] bug1 SUMMARY Some of GMIC's filters don't work very well when importing the results into krita. I found two so far (they have in common that they export multiple layers) I seem to remember seeing a discussion about this at one point, but I can't find it, so I'll report back here. BUG1：“channels to layers” from a single layer to multiple layers. However 1 Only one layer's position remains the same, the other layers are generated in the upper left corner 2 The name is not standardized. The result should be [test] [red], [test] [green], [test] [blue] 3 The blend mode was not properly selected. [red] is "addition" and [green] is "normal" It should look like the following. RGB - R (addition), G (additon), B (normal) CMY - BASE (difference), C (difference), M (difference), Y (normal) HSV - V (mulpitly), HS (normal)
Created attachment 147883 [details] bug2 bug2：“decompose channels” 1. None of the layers are in the correct position 2. The name is not standardized
Created attachment 147884 [details] bug3 bug3 If gmic exports more than one layer, then the "undo" function will have problems. 1. The blend mode will not change to the original 2. After redoing, there is still only one layer
It'll take me a while to triage, I'm pretty busy preparing a talk about Krita right now. Thanks for the report!
So: BUG1: "channels to layers" 1 Trying to reproduce now, no success yet. Can you send a file with affected layers? 2 Fixed in https://invent.kde.org/graphics/krita/-/commit/37d49dc6b9144760c0d4872dda4fb61af541b6bb (master branch, seems I forgot to cherry pick it) 3 Fixed in https://invent.kde.org/graphics/krita/-/commit/a1dbad405f55fd352e0d45c9df09c2bfc9abeeec (master and 5.0.5) BUG2: “decompose channels” 1. Cannot reproduce. G'MIC log says that all layers must be anchored in (0, 0) (we send the whole canvas to them, not just the small image). 2. Same as 1.2 BUG3: Undo issues 1. Confirmed 2. Confirmed
(In reply to amyspark from comment #4) > So: > > BUG1: "channels to layers" > > 1 Trying to reproduce now, no success yet. Can you send a file with affected > layers? > 2 Fixed in > https://invent.kde.org/graphics/krita/-/commit/ > 37d49dc6b9144760c0d4872dda4fb61af541b6bb (master branch, seems I forgot to > cherry pick it) > 3 Fixed in > https://invent.kde.org/graphics/krita/-/commit/ > a1dbad405f55fd352e0d45c9df09c2bfc9abeeec (master and 5.0.5) > > BUG2: “decompose channels” > 1. Cannot reproduce. G'MIC log says that all layers must be anchored in (0, > 0) (we send the whole canvas to them, not just the small image). > 2. Same as 1.2 > > BUG3: Undo issues > 1. Confirmed > 2. Confirmed BUG1:“channels to layers” 1.I forgot to mention that I used a selection to prevent the transparent area from turning black 2.the names have all become [unnamed]. Is it possible to read the original layer names?It should be [test] [red], [test] [green], [test] [blue] or others. 3.For "HSV mode", "mulpitly" is more appropriate than "value HSV" (I don't know why, but the result of "value HSV" is different from the original image) For the other two, I want the bottom layer's blending mode to be "normal", otherwise it will be blended.(or put the results in a group) BUG2: “decompose channels” 1.It still has problems with its position, and unlike 1.1, it can cause position anomalies without using selection. And a large part of it is outside the canvas. I will upload the file afterwards. 2.same to 1.2 file：https://ufile.io/60t3dry8
Ohh, thanks for your response! BUG1: “channels to layers” 1. and 2. stem from an issue in my plugin, I mistakenly kept the v4 mangling when getting the layer property string. That'll be fixed in my fork. 3. The blending mode comes from G'MIC's own specification, in this case it tells us all three channels have the mode "alpha" (i.e. treat as normal channel layer): > [gmic]-1./fx_decompose_channels/*if/*repeat/(...)/*repeat/gui_set_layer_name/*repeat/*local/ Set local variable 'opacity=100'. > [gmic]-1./fx_decompose_channels/*if/*repeat/(...)/*repeat/gui_set_layer_name/*repeat/*local/ Set local variable 'mode=alpha'. > [gmic]-1./fx_decompose_channels/*if/*repeat/(...)/*repeat/gui_set_layer_name/*repeat/*local/ Set local variable 'pos=0,0'. > [gmic]-1./fx_decompose_channels/*if/*repeat/(...)/*repeat/gui_set_layer_name/*repeat/*local/ Set name of image [0] to 'name(Background [H]),mode(alpha),opacity(100),pos(0,0)'. > [gmic]-1./fx_decompose_channels/*if/*repeat/(...)/*repeat/gui_set_layer_name/*repeat/*local/ Set local variable 'opacity=100'. > [gmic]-1./fx_decompose_channels/*if/*repeat/(...)/*repeat/gui_set_layer_name/*repeat/*local/ Set local variable 'mode=alpha'. > [gmic]-1./fx_decompose_channels/*if/*repeat/(...)/*repeat/gui_set_layer_name/*repeat/*local/ Set local variable 'pos=0,0'. > [gmic]-1./fx_decompose_channels/*if/*repeat/(...)/*repeat/gui_set_layer_name/*repeat/*local/ Set name of image [0] to 'name(Background [S]),mode(alpha),opacity(100),pos(0,0)'. > [gmic]-1./fx_decompose_channels/*if/*repeat/(...)/*repeat/gui_set_layer_name/*repeat/*local/ Set local variable 'opacity=100'. > [gmic]-1./fx_decompose_channels/*if/*repeat/(...)/*repeat/gui_set_layer_name/*repeat/*local/ Set local variable 'mode=alpha'. > [gmic]-1./fx_decompose_channels/*if/*repeat/(...)/*repeat/gui_set_layer_name/*repeat/*local/ Set local variable 'pos=0,0'. > [gmic]-1./fx_decompose_channels/*if/*repeat/(...)/*repeat/gui_set_layer_name/*repeat/*local/ Set name of image [0] to 'name(Background [V]),mode(alpha),opacity(100),pos(0,0)'. BUG2: “decompose channels” 1. and 2. If the altered position comes from Krita, then same as above. I'll now check with your file.
> 3. The blending mode comes from G'MIC's own specification, in this case it > tells us all three channels have the mode "alpha" (i.e. treat as normal > channel layer): I don't quite understand here. I doubt we're not talking about the same thing… In other words, we don't have the right to customize the blending mode?I remember that gmic also supports some other softwares, but "value hsv" is unique to krita. I find it hard to imagine that they would lock "value hsv" internally instead of using "mulpitly". All in all, you can hide the top layer to match bug1.3 for comparison.
> In other words, we don't have the right to customize the blending mode?I remember that gmic also supports some other softwares, but "value hsv" is unique to krita. I find it hard to imagine that they would lock "value hsv" internally instead of using "mulpitly". This is correct. G'MIC-Qt is only a user interface shim, to which I add the necessary IPC capabilities; we don't have any knowledge of the provenance of the images that G'MIC returns, so we cannot provide that kind of customization unless it's returned from the G'MIC code itself.
Bugs 1 and 2 have been fixed in my fork. The remainder of Bug 3 is part of https://invent.kde.org/graphics/krita/-/merge_requests/1428
Git commit 21e468f2c1426bbf7a48bba436d857adc44ba587 by L. E. Segovia. Committed on 26/04/2022 at 13:32. Pushed by lsegovia into branch 'master'. G'MIC: fix layer positioning and bounding Since this is a bug in *both* sides of the comms, we also need a G'MIC update. Related: bug 452831 M +1 -1 3rdparty_plugins/ext_gmic/CMakeLists.txt [INFRASTRUCTURE] M +1 -0 plugins/extensions/qmic/kis_import_qmic_processing_visitor.cpp M +1 -1 plugins/extensions/qmic/kis_qmic_interface.cpp M +3 -2 plugins/extensions/qmic/kis_qmic_simple_convertor.cpp M +2 -2 plugins/extensions/qmic/kis_qmic_synchronize_image_size_command.cpp https://invent.kde.org/graphics/krita/commit/21e468f2c1426bbf7a48bba436d857adc44ba587
Git commit 247e82508d750c7499f1e2c941cd177cd2829020 by L. E. Segovia. Committed on 26/04/2022 at 15:46. Pushed by lsegovia into branch 'master'. Refactor G'MIC glue code This commit refactors the complete G'MIC image import process, making all steps into Krita commands. This allows undoing and redoing G'MIC filters, which was previously not possible for two reasons: - layer properties application was done in-situ (thus the undo system was not aware of them, so undo was incomplete for reused layers) - layer insertion was not only done in-situ, but it also altered the internal state of the command (thus making redoing impossible) This commit performs the following: - Removal of all unused (pre Krita 5) code. - Reimplementation of the layer synchronization command into a composite command. - Reimplementation of the layer metadata processing and image composite functions from the applicator into separate, fully undoable commands. - Switch of the processing visitor's layer metadata processing to a separate, undoable command (see above). - Fix leaking the G'MIC image data on KisQMicImage destruction. - Simplification of the KisImageInterface application step by de-signal-slotting it. Related: bug 452831 CCMAIL: kimageshop@kde.org M +1 -4 plugins/extensions/qmic/CMakeLists.txt M +11 -13 plugins/extensions/qmic/QMic.cpp M +3 -16 plugins/extensions/qmic/QMic.h M +19 -11 plugins/extensions/qmic/gmic.h D +0 -135 plugins/extensions/qmic/kis_import_qmic_processing_visitor.cpp D +0 -56 plugins/extensions/qmic/kis_import_qmic_processing_visitor.h D +0 -114 plugins/extensions/qmic/kis_qmic_applicator.cpp D +0 -52 plugins/extensions/qmic/kis_qmic_applicator.h D +0 -26 plugins/extensions/qmic/kis_qmic_data.cpp D +0 -37 plugins/extensions/qmic/kis_qmic_data.h A +103 -0 plugins/extensions/qmic/kis_qmic_import_tools.h [License: GPL(v2.0+)] M +86 -62 plugins/extensions/qmic/kis_qmic_interface.cpp M +0 -5 plugins/extensions/qmic/kis_qmic_interface.h A +87 -0 plugins/extensions/qmic/kis_qmic_processing_visitor.cpp [License: GPL(v2.0+)] A +37 -0 plugins/extensions/qmic/kis_qmic_processing_visitor.h [License: GPL(v2.0+)] D +0 -75 plugins/extensions/qmic/kis_qmic_progress_manager.cpp D +0 -42 plugins/extensions/qmic/kis_qmic_progress_manager.h M +2 -2 plugins/extensions/qmic/kis_qmic_simple_convertor.cpp M +2 -2 plugins/extensions/qmic/kis_qmic_simple_convertor.h M +106 -72 plugins/extensions/qmic/kis_qmic_synchronize_layers_command.cpp M +12 -19 plugins/extensions/qmic/kis_qmic_synchronize_layers_command.h https://invent.kde.org/graphics/krita/commit/247e82508d750c7499f1e2c941cd177cd2829020