Created attachment 148287 [details] G'MIC output (single layer). SUMMARY When a G'MIC filter produces an image that is smaller than the input image, the resulting layer is not resized to the output image size. This happens at least with a rectabgular RGB input image and a filter that produces a square RGBA image (filter 'Colors / Colorful Blobs'). STEPS TO REPRODUCE 1. Open rectangular RGB image (mine was 1024x576). 2. Open G'MIC, select filter 'Color / Colorful Blobs' and click 'OK'. 3. Resulting layer is not square: the right part of the image still contains the input image data (see attached screenshot). OBSERVED RESULT EXPECTED RESULT SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: (available in About System) KDE Plasma Version: KDE Frameworks Version: Qt Version: ADDITIONAL INFORMATION
Actually a dup of 452831, but it's better to keep this one for deduplication purposes :D
David, from the looks of it, we only resize (expand) the image when the incoming layers are bigger. We cannot *shrink* the image because it may be the case that G'MIC hasn't consumed other, bigger layers. I do will implement the individual layer shrinkage and repositioning, as it's also needed in 452155 itself.
Interesting. Just curious, does that mean that in Krita, all layers have the same size ? (it is not the case in GIMP). If so, this is something I have to take into account, e.g. for filters that produce smaller layer that are positioned at coordinates that should be different from the (top,left) coordinates of the image.
> does that mean that in Krita, all layers have the same size No, I never said this. In fact, the image in bug 452155 is actual proof of that; the image has a size, and the size of the layesr is the size of their underlying paint device (which can be less than or equal to the image size). > for filters that produce smaller layer that are positioned at coordinates that should be different from the (top,left) coordinates of the image G'MIC actually already does this, it's us that were ignoring this data; in fact, not until last year did we start parsing it, and only now did I learn of a filter that could exercise that code path.
David, while I am fixing this, one question. When a layer A gets replaced with 3 others, B, C, and D, what's the order in which you expect them to be inserted in the receiving application? - B atop C atop D - D atop C atop B
In G'MIC, the layers are ordered from the top to the bottom in the image list. So image [0] is always the top layer, etc.
Being targeted as part of https://invent.kde.org/graphics/krita/-/merge_requests/1428
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 452155 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