Bug 217124

Summary: PaintOps that copy pixels are not aware of pixel transparency
Product: [Applications] krita Reporter: enkithan
Component: GeneralAssignee: LukasT <lukast.dev>
Status: RESOLVED WAITINGFORINFO    
Severity: major CC: animtim, cberger, halla
Priority: NOR Keywords: release_blocker
Version: unspecified   
Target Milestone: ---   
Platform: unspecified   
OS: Linux   
Latest Commit: Version Fixed In:

Description enkithan 2009-12-02 22:12:53 UTC
Version:           2.2 Alpha 1 (using 4.3.4 (KDE 4.3.4), Arch Linux)
Compiler:          gcc
OS:                Linux (x86_64) release 2.6.31-ARCH

all the paintops that move pixels don't work well with transparency:

deform brush & smudge brush: 
- half-opaques pixels becomes fully opaque. It seems it's because opacity is added for each iteration instead of mixed (?).
- fully transparent pixels are ignored (they should be moved/copied as any other pixels instead)

filter brushes :
- some filters, like color to alpha & hsv, turn fully transparent pixels to opaque pixel.
- other filters, like pixelize, only turn half-opaque pixel to fully-opaque.

duplicate op :
-half-opaque and fully opaque pixel are replaced by fully opaque black pixels.

I think it's an important bug:
-it makes these paintop almost useless on transparent layers.
-there is a completely different result and behavior compared to painting on an opaque layer.
-an unwanted black color is generated that is almost impossible to remove.
Comment 1 Halla Rempt 2010-01-20 16:01:39 UTC
Ack, I see this. It can give very interesting results, but it is a horrible bug.
Comment 2 Cyrille Berger 2010-08-30 15:22:41 UTC
it would need to be implemented as a "mode" then, because you can get pretty impressive effect with the deform brush and transparent layer, for instance the river on the bottom right of this image: http://blog.cberger.net/2010/08/15/deforme-2/
Comment 3 LukasT 2010-09-07 17:33:25 UTC
SVN commit 1172609 by lukast:

o fix moving the pixels
o enumerify

Copy the pixels that are not touched by preset to workaround COMPOSITE_COPY not respecting the selection.
Create selection mask in yes/no style -- composite only pixels we touch.

New bug is that deform now does not respect selection now :(
There is pending review on patch in review board.

When you want to move the pixels, select COPY mode, not NORMAL.

CCBUG:217124

 M  +56 -25    deform_brush.cpp  
 M  +5 -3      deform_brush.h  
 M  +32 -1     kis_deform_paintop.cpp  
 M  +5 -0      kis_deform_paintop.h  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1172609
Comment 4 LukasT 2010-09-14 19:11:07 UTC
SVN commit 1175304 by lukast:

Fixing the mixing of the transparent pixels in COPY mode.

Use new KoCompositeOpCopy2 in the colorspaces.
Remove the KoCompositeOpCopy from the abstract colorspace which is the base class
for the colorspaces.

Leave the old composite copy around, it is still used in KoCtlColorSpace.

CCBUG:245130
CCBUG:217124

 M  +1 -2      KoColorSpaceAbstract.h  
 M  +2 -0      compositeops/KoCompositeOps.h  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1175304
Comment 5 LukasT 2010-09-22 11:34:38 UTC
I think deform and duplicate works now. Don't forget to choose the copy mode when testing. Can you give some feedback?

I think smudge is not working as it supposed to yet with trasparent pixels
http://bugs.kde.org/245130
Comment 6 animtim 2010-09-30 18:15:59 UTC
I confirm Deform and Duplicate brushes work right in copy mode,
but Smudge brush doesn't (as I reported in bug 245130 ).
Comment 7 animtim 2010-09-30 18:19:05 UTC
Also filter brush (wich has the same bug) doesn't have Copy mode available, so I can't give a try on it.
Comment 8 animtim 2010-12-03 16:45:29 UTC
Now Copy mode is available for filter brush, but when trying to use it with for instance a blur filter, it works very bad.

Also the remaining issue with smudge brush only happens with size mapped to pressure (with size setting unchecked it works OK )
Comment 9 Halla Rempt 2011-06-11 14:17:48 UTC
Resolving all needinfo bugs from 2009 and 2010.