| Summary: | Transform tool produces white artifacts around the edge of transformed result | ||
|---|---|---|---|
| Product: | [Applications] krita | Reporter: | acc4commissions |
| Component: | Tools/Transform | Assignee: | Dmitry Kazakov <dimula73> |
| Status: | ASSIGNED --- | ||
| Severity: | normal | CC: | dimula73, tomtomtomreportingin |
| Priority: | NOR | ||
| Version First Reported In: | git master (please specify the git hash!) | ||
| Target Milestone: | --- | ||
| Platform: | Compiled Sources | ||
| OS: | All | ||
| Latest Commit: | https://invent.kde.org/graphics/krita/commit/4d849b266ab32593b25ad1a43d32b2b132361dae | Version Fixed In: | |
| Sentry Crash Report: | |||
|
Description
acc4commissions
2021-09-08 19:29:39 UTC
Additional discussion: https://krita-artists.org/t/transform-tool-produces-white-artifacts-around-the-edge-of-transformed-result/28772 Confirming. Can we get this fixed sooner if it's not that hard to fix please. It's very pesky to be forced to wrap the whole drawings when using liquify, and I can't ever use the liquify at all on complicated paintings, because it would leave blade scars on them. It slows down the workflow quite a lot. Also if I may add : it'd be nice to have liquify has the edges stick to the selection edges and stretched, so we don't have to worry about not touching the edges or matching the edges while transforming. I guess the bug has too independent parts: the problem in Free Transform mode and the problem in Liquify mode. The problem in Free Transform mode is, most probbably, related to some bug in KisFilterWeightsApplicator. Most probably, it does alpha channel premultiplication somehow wrongly... Or, perhaps there is some precision issue. The proof is that four-point perspective transform doesn't have this issue. Four-point transform uses mix-op directly, so it does premultiplication correctly. Git commit 4d849b266ab32593b25ad1a43d32b2b132361dae by Dmitry Kazakov.
Committed on 24/03/2022 at 13:56.
Pushed by dkazakov into branch 'master'.
Fix bright halos in the transform tool around semi-transparent objects
We had a weird and very old (from 2008) non-linearity in KoMixColorsOp,
which clamped the totalAlpha channel in case it is "not sane". I have
a feeling that this construct was used to just make clamp the alpha
channel value into the destination color space bit depth. Though it
didn't take into accound that with some filters (bicubic, lanczos)
the weight may be negative, basically making this check invalid.
The patch simply removes this change and clamps the alpha channel
separately (since we do already have the same clamping for other
channels).
WARNING: think twice before porting that into 5.0 branch! The patch
changes how KoMixColorsOp works, so it might lead to unexpected
consequences.
M +60 -0 libs/image/tests/kis_filter_weights_applicator_test.cpp
M +2 -0 libs/image/tests/kis_filter_weights_applicator_test.h
M +9 -8 libs/pigment/KoMixColorsOpImpl.h
https://invent.kde.org/graphics/krita/commit/4d849b266ab32593b25ad1a43d32b2b132361dae
It's not fixed. :/ The halo is gone on free transform but still happens on liquify. Use freehand selection -> liquify Even a click somewhere will produce halos around the edge. I can reproduce the problem in Liquify as well. Steps: 0. Fill a large area. 1. Select freehand selection tool. 2. While in Vector Selection or Pixel Selection (with anti-aliasing) mode, select a large circle. 3. Select transform tool and activate liquify. 4. Click once inside the circle (this is necessary). 5. Hit enter, deselect, observe. Reopening. Ah, liquify! Yes, I've completely forgot about that, thanks! :) Hi, acc4commissions and tomtomtom! I have a feeling that the liquify issue is not-a-bug. The problem happpens because, when you start a transformation, the transform tool makes a normal "Cut" operation (the same as when you do Cut/Paste). This operation cannot add-up to a solid color. To workaround the issue one needs to use "Cut (sharp)" + "Paste" and then transform. Could you tell if this approach would solve your issue? Sounds like a usability issue... are there advantages to it being a unsharpened cut rather than a sharpened cut, when the user already has a choice between aliased and antialiased selections? Now I'm wondering if it's really necessary to have "soft" cut/copy operations, at least as the default operations... Having Cut (Sharp) as a separate action seems a bit unnecessary if the user has already chosen to use aliased selections, especially as Cut (sharp) doesn't have the same fallbacks as normal Cut (for cutting layers etc.). Additional confusion might occur when both normal cut and sharp cut will in practice produce a soft cut when the selection is antialiased, while with aliased selections they work as they would convey. "Additional confusion might occur when both normal cut and sharp cut will in practice produce a soft cut when the selection is antialiased, while with aliased selections they work as they would convey." Scratch this bit... aliased selections will always sharply cut regardless of operation, and antiliased selections will always softly cut regardless of operation. This is confusing to test. Regardless, and as follows, the workaround does not appear to work in the case of antialiased selections. Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone! This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging Thank you for helping us make KDE software even better for everyone! I really hope this will be addressed in the future as a feature request, to be able to liquify or cut/paste area without worrying about the artifacts/mismatch around the edge that the user didn't even touch. (In reply to Dmitry Kazakov from comment #10) > Hi, acc4commissions and tomtomtom! > > I have a feeling that the liquify issue is not-a-bug. The problem happpens > because, when you start a transformation, the transform tool makes a normal > "Cut" operation (the same as when you do Cut/Paste). This operation cannot > add-up to a solid color. To workaround the issue one needs to use "Cut > (sharp)" + "Paste" and then transform. Could you tell if this approach would > solve your issue? And this didn't solve the problem, when I cut/paste the layer there are transparent artifacts around the edge. This whole thing doesn't (perhaps only visually) happens tho, when the Rectangular Selection is used instead of other selecting methods. It used to not be like this tho, as far as I remember. I'm not sure since when it started to happen. |