Bug 176536

Summary: unexpected behavior of eraser, copy, add and substract modes
Product: [Applications] krita Reporter: enkithan
Component: GeneralAssignee: Cyrille Berger <cberger>
Status: RESOLVED FIXED    
Severity: normal CC: cberger, halla
Priority: NOR    
Version: unspecified   
Target Milestone: ---   
Platform: unspecified   
OS: Linux   
Latest Commit: Version Fixed In:
Sentry Crash Report:
Attachments: substract composite mode (using the pixel brush paintop)
comparison of substract and burn mode in gimp and krita (8bit RGB colorspace)
comparison of the overlay composite mode in gimp(left) and krita(right)
a better image and explanation for the transparency bug

Description enkithan 2008-11-30 12:52:30 UTC
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).
Comment 1 Cyrille Berger 2009-02-21 20:13:04 UTC
Can't reproduce for "eraser". Not sure if the "copy" mode should be user visible ?
Comment 2 Cyrille Berger 2009-02-21 20:32:58 UTC
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
Comment 3 Cyrille Berger 2009-02-21 20:41:32 UTC
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...
Comment 4 enkithan 2009-02-22 19:58:43 UTC
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.
Comment 5 Cyrille Berger 2009-02-22 21:10:35 UTC
For me, the eraser only break after "copy", but work after "Normal" (and everything break after copy)
Comment 6 enkithan 2009-02-22 22:31:06 UTC
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.
Comment 7 enkithan 2009-09-30 20:59:12 UTC
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).
Comment 8 enkithan 2009-09-30 21:23:06 UTC
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.
Comment 9 enkithan 2009-09-30 21:41:12 UTC
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.
Comment 10 enkithan 2009-10-01 16:42:03 UTC
Created attachment 37298 [details]
a better image and explanation for the transparency bug
Comment 11 Cyrille Berger 2009-11-08 21:39:17 UTC
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
Comment 12 Cyrille Berger 2009-11-08 21:46:12 UTC
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.
Comment 13 Cyrille Berger 2009-11-12 21:36:53 UTC
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
Comment 14 Cyrille Berger 2009-11-20 21:18:07 UTC
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
Comment 15 Cyrille Berger 2010-03-05 08:27:39 UTC
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