Bug 316858

Summary:	Artifacts with sketch brush on float colorspaces.
Product:	[Applications] krita	Reporter:	animtim
Component:	Brush engines	Assignee:	Dmitry Kazakov <dimula73>
Status:	RESOLVED FIXED
Severity:	normal	CC:	dimula73, halla, M8R-nvuxt11
Priority:	NOR
Version:	git master (please specify the git hash!)
Target Milestone:	---
Platform:	Other
OS:	Linux
Latest Commit:	http://commits.kde.org/calligra/e3a1b70ebf472a9b2edbbd7afc3c70c0644a6ef6	Version Fixed In:

Description animtim 2013-03-16 19:07:42 UTC

When using 16 or 32bits float canvas, the sketch brush leaves a weird artifact at the begining of each stroke. Also when trying to paint over those artifacts with another brush, any not-100%-opaque wont paint over them (like if those pixels are stuck..).

Reproducible: Always

Steps to Reproduce:
1.Create a file with 16 or 32bit float and scRGB linear colorspace.
2.Select any sketch preset (or select the preset "sketch_speedpaint" where it's easy to see the artifact)
3.start to paint strokes. Ideally start next stroke on previous stroke to see clearly artifacts color.

Then you may select a pixel-brush airbrush preset and try to paint over the artifacts, you'll see they stay "stuck" (try then with a preset like Basic_paint_fill and see here it can paint over artifacts).

Comment 1 Dmitry Kazakov 2013-03-26 12:50:58 UTC

There might be some problem in implementation of 16/32 bit compositioning (do we use opencolorio for that or what?). I don't have 16 support here (miss some dependancy), and I don't have this problem with 32bit float rgb colorspace. But I have another problem: I have RGBA/BGRA channels swapped in the color selector =)

Comment 2 Halla Rempt 2013-03-26 14:26:19 UTC

no, opencolorio is only used for display color correction. It's lcms2 that provides support for float colorspaces, and krita that provides support for composite ops -- we use the same templates here as for the other color spaces.

In any case, I don't think I can reproduce the artefacts with my wacom, though there is a bit of weirdness with the mouse -- the line starts fairly light.

Can you do a screenshot or screencap, please?

Comment 3 animtim 2013-03-26 18:12:11 UTC

Here is the screenshot (i sent the link on irc but forgot to add the link to the report, sorry)
http://timotheegiet.com/images/krita/sketchbugfloat.png

Comment 4 animtim 2013-03-26 18:40:22 UTC

And here is a screencast (note the bug is a bit different than before, now the weird "artifact" is no more "stuck", but still happens.. also you'll see colors are wrong at least on 32bit float, but this is probably another bug)

http://timotheegiet.com/images/krita/out_0003.mkv

Comment 5 Halla Rempt 2013-03-31 11:37:41 UTC

Ack. Now we only need to fix it.

Comment 6 Halla Rempt 2013-03-31 11:38:27 UTC

I've also seen a report that on rgb8, there can be a blue dot at the start.

Comment 7 Halla Rempt 2013-04-06 12:31:28 UTC

*** Bug 317556 has been marked as a duplicate of this bug. ***

Comment 8 Halla Rempt 2013-04-06 12:32:11 UTC

This happens at all colorspaces. After testing, it turns out that the bug occurred first after 2e051d3e81e9042fa3404a3d38efc656ad0d28d0, the kispainter refactoring for painting on masks.

Comment 9 Dmitry Kazakov 2013-04-09 08:29:04 UTC

Hm.. I've reproduced it.

Comment 10 Dmitry Kazakov 2013-04-19 06:32:00 UTC

Git commit e3a1b70ebf472a9b2edbbd7afc3c70c0644a6ef6 by Dmitry Kazakov.
Committed on 19/04/2013 at 08:31.
Pushed by dkazakov into branch 'master'.

Fix initialization of the internal painter of the Sketch PaintOp

The painter was not initialized with the paint color before the first
iteration of the loop. That meant the first segment of the connecting
line was painted with a random color.

M  +2    -2    krita/plugins/paintops/sketch/kis_sketch_paintop.cpp

http://commits.kde.org/calligra/e3a1b70ebf472a9b2edbbd7afc3c70c0644a6ef6