| Summary: | 'Split Alpha' creates unexpected edges with some brush blending modes | ||
|---|---|---|---|
| Product: | [Applications] krita | Reporter: | acc4commissions |
| Component: | General | Assignee: | Dmitry Kazakov <dimula73> |
| Status: | RESOLVED NOT A BUG | ||
| Severity: | normal | CC: | dimula73, griffinvalley |
| Priority: | NOR | ||
| Version First Reported In: | nightly build (please specify the git hash!) | ||
| Target Milestone: | --- | ||
| Platform: | Microsoft Windows | ||
| OS: | Microsoft Windows | ||
| See Also: | https://bugs.kde.org/show_bug.cgi?id=410516 | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
| Attachments: |
the file
(capture) black artifacts in vector text areas (capture) resulting edges |
||
|
Description
acc4commissions
2019-11-22 06:20:57 UTC
Created attachment 124058 [details]
(capture) black artifacts in vector text areas
Created attachment 124059 [details]
(capture) resulting edges
Hi, acc4commisions! That is a very interesting report :) I've never though about these effects. Most of them are the consequence of the design decisions we did for optimization purposes. So before explaining them I would like to ask you, what is your workflow? Why do you want these edges to be smooth? Detailed explanation: > 'Normal' produces blocky edges. By definition, when alpha is null, the value of color channels is undefined (in normal user workflow). Therefore, if we know that the destination alpha is null, we just copy the color of source channels, disregarding alpha. It is faster, and normal users will not see the difference. And you see blocky edges, because in "Normal" composite op we don't operate on individual pixels, but on strides of 8(!) pixels (due to AVX CPU optimizations). If you go to Settings->Performance->Disable AVX Optimizations and restart Krita you'll see that the edges become less blocky, like in "Overlay", but without artifacts. > 'Overlay', ... etc produces sharp edges with artifacts It happens because of a division in 8-bit numerical space. When alpha is low, then division/multiplication operations become non-stable. If you switch to 32-bit float color space, then the bug will disappear. Theoretically, we can try to fix it: Normal doesn't have this effect, though it has a little bit different blending. Though it might take quite a bit of time with uncertain results. > Only 'Luminosity / Shine (SAI)' produces the smooth result It is actually a bug in 'Luminosity / Shine (SAI)' and it should be fixed with 410516 :) This blending mode blends-in black color into the edges, which makes the edge look smooth. Just compare the strokes on white background. > Plus, there's this weird black triangles appears in vector text areas... Yes, it is a bug and should be fixed. It would be better if you added a separate ticket for that. Actually I don't care about this particular bug. I just reported it because it seemed related to 410516. :) So if you need to ignore this for any development purpose I won't mind. Just hope this report helped. > > Plus, there's this weird black triangles appears in vector text areas... > > Yes, it is a bug and should be fixed. It would be better if you added a > separate ticket for that. https://bugs.kde.org/show_bug.cgi?id=414581 I guess confirmed. (In reply to wolthera from comment #6) > I guess confirmed. As a user I don't even consider this an issue to be honest. I doesn't cause any problem in the actual painting process. Like I said I reported this because it seemed related to another bug(410516), but yeah, I'm not against fixing it either... Okay, the bug looks really interesting, but I don't think we can fix it without changing behavior and speed of existing blending modes. The only exception is 'Luminosity / Shine (SAI)', but it has its own bugreport in bug 410516. And since the big does not cause any real workflow problems to the reporter, I guess we can just close it :) Thank you, acc4commissions, for a really interesting observation! :) |