Created attachment 109864 [details] [Test file: a PNG with a character painted with greyscale] Hi! I have issue with the Gradient map filter being not really WYSIWYG in my tests. To reproduce: ============= 1. Open the test file in attachment: Spring-greyscale-painting.png 2. Open the filter: Filter > Map > Gradient Map 3. Pick a gradient in the presets (eg: GPS Fire Blueish) Result: ======= https://www.peppercarrot.com/extras/temp/2018-01-14_screenshot_220324_net.jpg The color of the gradient doesn't map to the picture only a low percent of the gradient are mapped to the full artwork. Note: ===== Reproduced on compiled source, appimage4.0beta1 ; but Wolthera couldn't reproduce (IRC discution).
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)