Created attachment 117943 [details] Exported image showing artifacts I attached an image to illustrate. The .kra file is beyond the size limit. I only used paint and fill layers with normal blend mode. Visual artifacts occur in the nightly appimage when painting in RGB 32-bit float - not however in 16f, 16i or 8i and also not in LAB, CYMK, XYZ or Grayscale in any combination. It is most obvious with a pixel engine brush using wide spacing, but also occurs with the particle brush and the tangent normal brush. The tangent normal brush seems to be an exception, here the artifacts seem to apply once per painted brush tip instead of aligning to the canvas. I didn't notice it with the shape, sketch or color smudge engines. In 4.1.7 this problem didn't occur using the same file. Version: 4.2.0-pre-alpha (git b8d64d3) Qt Version (compiled): 5.10.0 Version (loaded): 5.10.0 OS Information Build ABI: x86_64-little_endian-lp64 Build CPU: x86_64 CPU: x86_64 Kernel Type: linux Kernel Version: 4.20.7-1-MANJARO Pretty Productname: Manjaro Linux Product Type: manjaro Product Version: unknown OpenGL Info Vendor: NVIDIA Corporation Renderer: "GeForce GTX 860M/PCIe/SSE2" Version: "4.6.0 NVIDIA 415.27" Shading language: 4.60 NVIDIA Requested format: QSurfaceFormat(version 3.0, options QFlags<QSurfaceFormat::FormatOption>(DeprecatedFunctions), depthBufferSize 24, redBufferSize -1, greenBufferSize -1, blueBufferSize -1, alphaBufferSize -1, stencilBufferSize 8, samples -1, swapBehavior QSurfaceFormat::SwapBehavior(DoubleBuffer), swapInterval 0, colorSpace QSurfaceFormat::ColorSpace(DefaultColorSpace), profile QSurfaceFormat::OpenGLContextProfile(CompatibilityProfile)) Current format: QSurfaceFormat(version 4.6, options QFlags<QSurfaceFormat::FormatOption>(DeprecatedFunctions), depthBufferSize 24, redBufferSize 8, greenBufferSize 8, blueBufferSize 8, alphaBufferSize 0, stencilBufferSize 8, samples -1, swapBehavior QSurfaceFormat::SwapBehavior(DoubleBuffer), swapInterval 0, colorSpace QSurfaceFormat::ColorSpace(DefaultColorSpace), profile QSurfaceFormat::OpenGLContextProfile(CompatibilityProfile)) Version: 4.6 Supports deprecated functions true is OpenGL ES: false Hardware Information GPU Acceleration: auto Memory: 15951 Mb Number of Cores: 8 Swap Location: /tmp
As far as I know, nothing has changed in the normal blending mode or the 32 bits float rgb colorspace since 4.1... All the work for HDR hasn't even been merged yet. I haven't reproduced the issue yet, but I'll mark it as regression in any case.
Created attachment 119297 [details] Shows errors made in 32bit float image. I can reproduce this on Krita Version: 4.2.0-pre-alpha (git c5838c0) Languages: en_US, en_GB, nl Hidpi: false Qt Version (compiled): 5.12.0 Version (loaded): 5.12.0 OS Information Build ABI: x86_64-little_endian-lp64 Build CPU: x86_64 CPU: x86_64 Kernel Type: linux Kernel Version: 4.15.0-46-generic Pretty Productname: KDE neon User Edition 5.15 Product Type: neon Product Version: 18.04
I thought I had set this to confirmed...
*** Bug 406400 has been marked as a duplicate of this bug. ***
Git commit d3e4c3aa299cf10a3ef167213f50799baba9c782 by Dmitry Kazakov. Committed on 24/05/2019 at 13:32. Pushed by dkazakov into branch 'krita/4.2'. Disable AVX optimizations for 32-bit composite ops in Krita 4.2 They cause artifacts and we don't have a fix yet :( M +13 -3 libs/pigment/compositeops/KoCompositeOps.h https://invent.kde.org/kde/krita/commit/d3e4c3aa299cf10a3ef167213f50799baba9c782
Created attachment 121275 [details] 32bit float color artifacts appear on the stable branch I've added the kritarc file, but I am not sure if this is the right configuration file Mr./Mrs. -tiar- was talking about. I have also added a Krita file with the problem in the title. Here is the conversation: https://www.reddit.com/r/krita/comments/c6x7wr/these_lines_how_do_i_get_rid_of_them/ For the brushes that make this happen, I noticed that I could reproduce this with almost every default pixel brush, even custom made. I've also noticed that when I press hard on my pen to get the maximum opacity, the artifacts don't appear. In simple terms, the lighter the opacity the clearer the artifact gets. If I tap lightly to paint, it gets even clearer for the brushes with pen sensitivity. The Hard round brush w/o pen sensitivity settings have only light to no artifacts around its perimeter
I forgot to mention in the "32bit float color artifacts appear on the stable branch" report. I run on MS windows 10 Pro 64-bit with 8 GB of ram. Krita version: 4.2.2 My GPUs: Intel HD 530 and GTX950m CPU: i5 6300HQ
4.2.1 did not have any artifacts.
Git commit cd5450a851ed2183fbb7ea479365efc114e94c26 by Agata Cacko, on behalf of Dmitry Kazakov. Committed on 06/07/2019 at 17:03. Pushed by tymond into branch 'master'. Disable AVX optimizations for 32-bit composite ops They cause artifacts and we don't have a fix yet :( Note from the committer: This commit was initially made on krita/4.2 branch. However between 4.2.1 and 4.2.2 the stable branch was reconstructed, which caused all commits that were exclusively on the previous krita/4.2 (and not on master) to be missing. The previous commit hash: d3e4c3aa299cf10a3ef167213f50799baba9c782 Also regarding the artifacts: it never worked, optimization were enabled during the creamy flow implementation, but they never should be enabled until someone fix them properly. M +14 -3 libs/pigment/compositeops/KoCompositeOps.h https://invent.kde.org/kde/krita/commit/cd5450a851ed2183fbb7ea479365efc114e94c26
The optimization never worked. They are disabled on master will be disabled on the stable branch as well, so users won't see it/won't have a problem. I unassign myself from this bug report since I couldn't find a cause and I won't be working on it for now.
(In reply to Tymond from comment #10) > The optimization never worked. They are disabled on master will be disabled > on the stable branch as well, so users won't see it/won't have a problem. > > I unassign myself from this bug report since I couldn't find a cause and I > won't be working on it for now. Thank you for trying (^-^) Your replies encouraged me to report bugs on Krita(#^^#)
Git commit c4428e2a635a8c15385db882f1ffb1d29c102640 by Boudewijn Rempt, on behalf of Dmitry Kazakov. Committed on 08/07/2019 at 14:59. Pushed by rempt into branch 'krita/4.2'. Disable AVX optimizations for 32-bit composite ops They cause artifacts and we don't have a fix yet :( Note from the committer: This commit was initially made on krita/4.2 branch. However between 4.2.1 and 4.2.2 the stable branch was reconstructed, which caused all commits that were exclusively on the previous krita/4.2 (and not on master) to be missing. The previous commit hash: d3e4c3aa299cf10a3ef167213f50799baba9c782 Also regarding the artifacts: it never worked, optimization were enabled during the creamy flow implementation, but they never should be enabled until someone fix them properly. M +14 -3 libs/pigment/compositeops/KoCompositeOps.h https://invent.kde.org/kde/krita/commit/c4428e2a635a8c15385db882f1ffb1d29c102640
Can confirm, this also happens on Windows 10 with both the 16-bit float/channel and 32-bit float/channel, using the 4.2.9-beta. one of the brushes this happens with is j)_Waterpaint_Soft_Edges
Git commit 999cd22e73339a5f4747be45d68ca7f7d9850e34 by Dmitry Kazakov. Committed on 13/01/2021 at 13:10. Pushed by dkazakov into branch 'master'. Recover AVX optimization for Float32 color spaces The problem was in the fast-path branch which used wrong pixel type Many thanks to Mathias Wein for tracking down this problem: https://invent.kde.org/graphics/krita/-/commit/76c28d6a29f1b5d5d7df76d40deb9f9e97d9f21c M +3 -13 libs/pigment/compositeops/KoCompositeOps.h M +6 -5 libs/pigment/compositeops/KoOptimizedCompositeOpAlphaDarken128.h M +5 -5 libs/pigment/compositeops/KoOptimizedCompositeOpOver128.h https://invent.kde.org/graphics/krita/commit/999cd22e73339a5f4747be45d68ca7f7d9850e34
Git commit a0494656a98d81ac269364dc2b45fb2841ecff3c by Dmitry Kazakov. Committed on 13/01/2021 at 13:11. Pushed by dkazakov into branch 'krita/4.3'. Recover AVX optimization for Float32 color spaces The problem was in the fast-path branch which used wrong pixel type Many thanks to Mathias Wein for tracking down this problem: https://invent.kde.org/graphics/krita/-/commit/76c28d6a29f1b5d5d7df76d40deb9f9e97d9f21c M +3 -13 libs/pigment/compositeops/KoCompositeOps.h M +6 -5 libs/pigment/compositeops/KoOptimizedCompositeOpAlphaDarken128.h M +5 -5 libs/pigment/compositeops/KoOptimizedCompositeOpOver128.h https://invent.kde.org/graphics/krita/commit/a0494656a98d81ac269364dc2b45fb2841ecff3c