Version: trunk (using KDE 4.1.3) Compiler: gcc 4.3.2 OS: Linux Installed from: Unlisted Binary Package archlinux x86_64 qtmod-4.4.3 kdemod 4.1.3 eigen2-svn 887763 koffice2-svn 890721 1. eraser, copy, add & substract modes ignore: - selections, using the fill, gradient or paint freely tools. - threshold of the fill tool. - brush tip masks of the paint freely tool for exemple: -Draw a circle selection, -fill it with the fill tools in substract mode -> pixels outside the selection are filled too. 2. substract & add don't works as expected (at least not like in all others raster editors) for exemple: the add mode can darken pixels. it should only being able to brighten pixels. It seems to works more like a kind of invert mode (except when pure color like a rgb8 255,0,0 is used).
Can't reproduce for "eraser". Not sure if the "copy" mode should be user visible ?
SVN commit 929647 by berger: Fix: Substract and Add now respect the selection, and aren't inverted when overloading make a template version of Add/Substract, which makes them usuable by other color spaces after 2.0 CCBUG:176536 M +1 -1 krita/image/tests/kis_painter_test.cpp M +1 -1 krita/ui/widgets/kis_cmb_composite.cc M +1 -1 libs/pigment/KoCompositeOp.h M +1 -1 libs/pigment/colorspaces/KoAlphaColorSpace.cpp M +4 -2 libs/pigment/colorspaces/KoRgbU8ColorSpace.cc M +1 -1 libs/pigment/colorspaces/KoRgbU8CompositeOp.cpp AM libs/pigment/compositeops/KoCompositeOpAdd.h [License: LGPL (v2+)] M +1 -0 libs/pigment/compositeops/KoCompositeOpAlphaBase.h AM libs/pigment/compositeops/KoCompositeOpSubstract.h [License: LGPL (v2+)] WebSVN link: http://websvn.kde.org/?view=rev&revision=929647
Hum, I can sort of reproduce with "erase"... if I use first "copy", then switch to "erase" (or any other composite ops), it starts to do strange things outside the selected area...
Created attachment 31552 [details] substract composite mode (using the pixel brush paintop) *substract still "inverts" colors here (trunk revision 930109): - On a white background, the first stroke turns pixels into black, whatever the color I paint with. - The second stroke makes the (black) color brighter. The resulting color is similar to the color set in the color chooser. -the funny "checker" strokes is produced by the build-up mode of the pixel brush paintop... I have to say I like it ^^. *About the eraser mode, I confirm it happens only after I use another composite mode.
For me, the eraser only break after "copy", but work after "Normal" (and everything break after copy)
After more testing, it appears that the Eraser mode wasn't becoming crazy because I was using others composite modes (except copy), but because I had the painting mode set to "build up". Sorry for the previous misleading comment.
Created attachment 37268 [details] comparison of substract and burn mode in gimp and krita (8bit RGB colorspace) both substract and burn mode should not allow the color to become lighter. with burn mode, it should looks as if pigments were more concentred (like yellow ink that becomes red in a ink cartridge, or when you draw with felt tip pens).
Created attachment 37270 [details] comparison of the overlay composite mode in gimp(left) and krita(right) It's very faint (you will have to download and zoom), but you can see that in krita, semi-transparent pixels(=smooth border) becomes more opaque where vertical lines overlap with horizontal lines. On the gimp screenshot you can see the smooth borders are perfectly smooth. Note that it happens for every composite modes I tried.
1.The add mode doesn't work either: it produces a transparent output and is misplaced in the mode combo box. 2.about substract bug : I think it is just inverted. for example : instead of : blue - white = black, it does : white - blue = yellow. white = top layer in substract mode. blue = bottom layer in normal mode.
Created attachment 37298 [details] a better image and explanation for the transparency bug
SVN commit 1046475 by berger: Do not use the "old" add composite op, especially since it is a bit broken CCBUG:176536 M +0 -1 KoRgbU8ColorSpace.cc WebSVN link: http://websvn.kde.org/?view=rev&revision=1046475
I am a bit annoyed by the "subtract" bug and the transparency thing. I wonder if "keeping" the current behaviour would not be useful too. This could be done either by "duplicating" composite operations, or by adding options.
SVN commit 1048158 by berger: Fix: the add composite op remove the old composite op add CCBUG:176536 M +0 -1 KoRgbU8ColorSpace.cc WebSVN link: http://websvn.kde.org/?view=rev&revision=1048158
SVN commit 1052114 by berger: makes Subtract behaves like the Gimp, and an inversed subtract CCBUG:176536 A KoCompositeOpInversedSubtract.h KoCompositeOpSubtract.h#1051612 [License: LGPL (v2+)] M +1 -1 KoCompositeOpSubtract.h M +3 -0 KoCompositeOps.h WebSVN link: http://websvn.kde.org/?view=rev&revision=1052114
SVN commit 1099196 by berger: Fix: composite op change the alpha of destination BUG:176536 M +2 -2 KoCompositeOpAdd.h M +2 -2 KoCompositeOpAlphaBase.h M +3 -3 KoCompositeOpBurn.h M +2 -2 KoCompositeOpDivide.h M +2 -2 KoCompositeOpDodge.h M +2 -2 KoCompositeOpInversedSubtract.h M +2 -2 KoCompositeOpMultiply.h M +2 -2 KoCompositeOpOver.h M +2 -2 KoCompositeOpOverlay.h M +2 -2 KoCompositeOpScreen.h M +2 -2 KoCompositeOpSubtract.h WebSVN link: http://websvn.kde.org/?view=rev&revision=1099196