[krita] [Bug 356462] Krita opacity bug
https://bugs.kde.org/show_bug.cgi?id=356462 --- Comment #8 from Boudewijn Rempt--- Oh, and just to note: mypaint does all its work internally in 16 bits premultiplied, iirc. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 356462] Krita opacity bug
https://bugs.kde.org/show_bug.cgi?id=356462 Boudewijn Remptchanged: What|Removed |Added CC||b...@valdyas.org --- Comment #7 from Boudewijn Rempt --- We used to do this in integers, afair, and it's still possible to specialize per color model/channel depth. I think we used to have just as many artefacts in the blending brush back then, though, if not more. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 356462] Krita opacity bug
https://bugs.kde.org/show_bug.cgi?id=356462 --- Comment #6 from wolthera--- I can't tell you about GIMP, but MyPaint just does it's normal blending mode in integers: https://github.com/mypaint/mypaint/blob/master/lib/blending.hpp (fix_15_t is a uint32_t and fix_15_t_short is a uint16_t) https://github.com/mypaint/mypaint/blob/master/lib/fix15.hpp I am not sure what benefit it has to us to use this method anywhere but in the normal/over/general lerp, but for normal/over/lerp it might actually be very useful. The real question I suposse is if this issue is problematic enough in 16bit to have it there as well. (the float spaces don't need it, because well, they're floats) -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 356462] Krita opacity bug
https://bugs.kde.org/show_bug.cgi?id=356462 Dmitry Kazakovchanged: What|Removed |Added CC||dimul...@gmail.com --- Comment #5 from Dmitry Kazakov --- Short: The solution for the original problem: "just use 51% opacity to avoid rounding, or use another composite op" Long: The formula for Normal alpha blending looks like that: newColor = dstColor + alpha * (srcColor - dstColor) In our case: dstColor = 1 srcColor = 0 alpha = 0.5 We do all the calculations in a floating point numbers, so we get: newColor = 1.0 + 0.5 * (0.0 - 0.5) = 0.5 Then, we convert the floating-point number back to integers using rounding: newColorInt = round(0.5) = 1 We cannot skip rounding, because if we do the effects will be drastic. The image pixels will flip to different sides in a random way, creating artifacts on the merged image. So, speaking truly, I don't know if we can (or should) fix this bug. How do the other applications work with this case? -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 356462] Krita opacity bug
https://bugs.kde.org/show_bug.cgi?id=356462 Sven Langkampchanged: What|Removed |Added CC||sven.langk...@gmail.com --- Comment #3 from Sven Langkamp --- It works here, but it depends a bit on how often you paint over the same place. With 50% opacity I have to paint about 8 times over to fully cover. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 356462] Krita opacity bug
https://bugs.kde.org/show_bug.cgi?id=356462 --- Comment #2 from wolthera--- Actually, no, now I think about it, the problem happens in the transparency code: Somehow we're not ending up with 100% transparency. You can test this by comparing the difference between 'pick from merged image' and 'pick from layer'. On 'pick from layer' we get full black. On 'pick from merged image' integer spaces give an offset. So the error happens in the transparancy-mixing code, and that it is unable to get to 100%. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 356462] Krita opacity bug
https://bugs.kde.org/show_bug.cgi?id=356462 woltherachanged: What|Removed |Added Component|Brush engine|Color models -- You are receiving this mail because: You are watching all bug changes.