Created attachment 148929 [details] pic SUMMARY *** krita-nightly-x64-5.1.0-prealpha-d59747b8ad As shown in the figure, the top is the preview in GMIC, and the bottom is the final result. The result is different from the preview. I think it's a translucent selection problem because I clicked on the layer thumbnail to create the selection. In theory, this result may be correct: the translucent selection selects only part of the image. The adjusted part will be mixed with the original image to show a new color. But the problem is: 1. The final result is not directly obtained, which needs to be predicted by the user 2. Assuming 1 is impossible, the preview in GMIC should not be 100% opaque This is easily misunderstood. *** STEPS TO REPRODUCE 1. Draw an opaque line 2. Create a selection and paint a part with 50% gray 3. Use a filter with large color changes
Going to check this with the rest of the bugs.
Created attachment 149038 [details] Demo G'MIC filter works, commit 110498d
I reopened it because the video described something different from what I said. The focus is not "translucent lines" but "translucent selection". You can also reproduce it through another process: 1. Draw a translucent line 2.select opaque（replace） 3.use GMIC There's another demo in the video (maybe you didn't see it, so I'll send it again)： https://ufile.io/gbf6rnq1
Hi, amyspark! Usually we use selections in the following way: 1) Copy selected pixels out of the source device into an empty device using COMPOSITE_OVER (or COMPOSITE_COPY) and a selection. 2) Erase the selection on the source device (with clearSelection()). 3) Transform the pixels on the separate device 4) Copy transformed pixels back into the source device using COMPOSITE_OVER (or COMPOSITE_COPY) blendmode As far as I can tell, KisImageInterface::gmic_qt_get_cropped_images() skips point 2), therefore there are leftovers left on the device. PS: Theoretically, we could use the blending method of the layer styles. It works better in some cases and avoids generation of halos. Though I'm not totally sure it'll work correctly in this particular case, when the cut piece can be transformed. The layer style's blending method is implemented in `KisLayerStyleProjectionPlane::apply`.
A possibly relevant merge request was started @ https://invent.kde.org/graphics/krita/-/merge_requests/1464
Git commit 6f7b289ad73bfca8874c05d1c92d1da338c9409b by L. E. Segovia. Committed on 02/06/2022 at 16:19. Pushed by lsegovia into branch 'master'. G'MIC: fix masking of selections M +0 -2 plugins/extensions/qmic/kis_qmic_import_tools.h https://invent.kde.org/graphics/krita/commit/6f7b289ad73bfca8874c05d1c92d1da338c9409b
Reopening due to private report. The KisPainter approach works well for compositing, but doesn't account for the need to *replacing* the pixels altogether.
This bug affects only compositing with selections that have been created via Select Opaque. Not sure what's going on with KisPainter...
Git commit 389448dd3976b8628dcc424e3da07801a3e5e241 by L. E. Segovia. Committed on 20/06/2022 at 00:47. Pushed by lsegovia into branch 'master'. G'MIC: fix composition of full pixel selections M +1 -0 plugins/extensions/qmic/kis_qmic_import_tools.cpp https://invent.kde.org/graphics/krita/commit/389448dd3976b8628dcc424e3da07801a3e5e241
Git commit a8a35883a4466dda80cd381570a47973b176b3f8 by L. E. Segovia. Committed on 20/06/2022 at 00:49. Pushed by lsegovia into branch 'krita/5.1'. G'MIC: fix composition of full pixel selections (cherry picked from commit 389448dd3976b8628dcc424e3da07801a3e5e241) M +1 -0 plugins/extensions/qmic/kis_qmic_import_tools.cpp https://invent.kde.org/graphics/krita/commit/a8a35883a4466dda80cd381570a47973b176b3f8
Reassigning to Halla as she'd be the best to assess if this should be expected behaviour or not.
Halla has determined opaque selections are intended to composite their value with the incoming modifications, not outright replacement of the pixels. Closing as NOT A BUG.