Summary: | [Gradient Map Filter] color mapping issue | ||
---|---|---|---|
Product: | [Applications] krita | Reporter: | David REVOY <info> |
Component: | Filters | Assignee: | Halla Rempt <halla> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | ghevan, griffinvalley, halla, paul.gieske |
Priority: | NOR | ||
Version: | git master (please specify the git hash!) | ||
Target Milestone: | --- | ||
Platform: | Compiled Sources | ||
OS: | Linux | ||
Latest Commit: | https://invent.kde.org/kde/krita/commit/0bb8b52570f54bd0a1b11d9309713edb0838d05f | Version Fixed In: | |
Sentry Crash Report: | |||
Attachments: |
[Test file: a PNG with a character painted with greyscale]
boud's result [^ screenshot of the bug: Krita 4.0.3appimage ] testing gradient map with 3 stops [^ screenshot of the bug solved (workaround) with new locales] |
Description
David REVOY
2018-01-14 21:21:43 UTC
I can reproduce it on the appimage, but not my local build, which makes it near impossible for me to figure out what is going on... Created attachment 109927 [details]
boud's result
Hm, I get a completely different result from Deevad; but the same result both with the beta 1 appimage and my master build
FYI I have the same issue as David. The gradient seems to map only between the gradient stops corresponding to the two lightest values. Example: ======== https://drive.google.com/open?id=1j-WbGxKMJ57JnUqdbO_oeXB2LXsKiHZY - only the green to red part of the spectrum is mapped - blue to green part of the spectrum is ignored To reproduce: ============= 1. Create a white to black spectrum 2. Add a gradient map filter with at least 3 stops Created attachment 112837 [details]
[^ screenshot of the bug: Krita 4.0.3appimage ]
Hi Paul,
Thanks for poking this bug-report.
I could easily reproduce it with Krita 4.0.3 appimage and with Krita~master (git a0899ca) on Linux using the same PNG as in the first post of this thread. (see screenshot in attachment). The default rainbow gradient is a good gradient to test this.
I still can confirm this bug in Git~master of today. New information: Gradient with only two color markers will work: eg: https://www.peppercarrot.com/extras/temp/2018-06-13_screenshot_164426_net.jpg If a third color or more is introduced, this new colors will be ignored: eg: https://www.peppercarrot.com/extras/temp/2018-06-13_screenshot_164537_net.jpg The two markers on right of the gradient are the only color affecting the gradient applied on canvas. Created attachment 113498 [details]
testing gradient map with 3 stops
I could not reproduce this bug, neither in master nor in 4.0.4 on the Mac builds.
I tested in many color spaces and bit depths and the resulting gradient map image is shown correctly.
Hi, Like David I am also working on Linux. I am using the appimage of Krita 4.0.0. Seems that this bug is specific to Linux. Rgds, Paul I wonder if it is not a bug related to a bug in Little CMS; I'm using:
> Found lcms version 2.08, /usr/lib/x86_64-linux-gnu/liblcms2.so
I'll try to build a newer version of liblcms, and rebuild Krita after that.
So, there's something weird going on with the serialisation of the gradient into xml. What that means is that on my system, it does always store the offsets properly, but they seem to get lost on deevad's system. My system: ---------- Krita Version: 4.2.0-pre-alpha (git cb3736e) OS Information Build ABI: x86_64-little_endian-lp64 Build CPU: x86_64 CPU: x86_64 Kernel Type: linux Kernel Version: 4.13.0-45-generic Pretty Productname: Ubuntu 17.10 Product Type: ubuntu Product Version: 17.10 Could it be a localisation issue? Deevad, is your system set to French? @boud: good idea. I have a mix; English lang, but French time/numeric/monetary... $ locale LANG=en_US.UTF-8 LANGUAGE= LC_CTYPE="en_US.UTF-8" LC_NUMERIC=fr_FR.UTF-8 LC_TIME=fr_FR.UTF-8 LC_COLLATE="en_US.UTF-8" LC_MONETARY=fr_FR.UTF-8 LC_MESSAGES="en_US.UTF-8" LC_PAPER=fr_FR.UTF-8 LC_NAME=fr_FR.UTF-8 LC_ADDRESS=fr_FR.UTF-8 LC_TELEPHONE=fr_FR.UTF-8 LC_MEASUREMENT=fr_FR.UTF-8 LC_IDENTIFICATION=fr_FR.UTF-8 LC_ALL= Could it be a problem of numeric? French write them 0,5 instead of 0.5; maybe this could lead the XML of the filter to reset all the offset to 0 if it tries to write them in respect to my locale, with comma... Created attachment 113608 [details]
[^ screenshot of the bug solved (workaround) with new locales]
@boud: 👍 big thumb up! It is a local issue with numeric and XML as Wolthera_laptop thought. It is now working after switching my numeric to US. (proof in attachement). There is certainly a bad comma/dot conversion somewhere.
Git commit 0bb8b52570f54bd0a1b11d9309713edb0838d05f by Boudewijn Rempt. Committed on 02/05/2019 at 10:22. Pushed by rempt into branch 'master'. Use KisDomUtils to read and write floats in gradients M +15 -14 libs/pigment/resources/KoSegmentGradient.cpp M +7 -5 libs/pigment/resources/KoStopGradient.cpp https://invent.kde.org/kde/krita/commit/0bb8b52570f54bd0a1b11d9309713edb0838d05f Thank you very much Boys! s/Boys/Boud (autocorrect issue on smartphone 's keyboard, sorry) |