Bug 388976

Summary: [Gradient Map Filter] color mapping issue
Product: [Applications] krita Reporter: David REVOY <info>
Component: FiltersAssignee: 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: 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
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).
Comment 1 wolthera 2018-01-14 21:29:37 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...
Comment 2 Halla Rempt 2018-01-17 11:24:00 UTC
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
Comment 3 Paul 2018-05-22 05:10:58 UTC
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
Comment 4 David REVOY 2018-05-23 16:35:29 UTC
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.
Comment 5 David REVOY 2018-06-13 14:48:22 UTC
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.
Comment 6 vanyossi 2018-06-22 01:17:00 UTC
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.
Comment 7 Paul 2018-06-22 09:10:57 UTC
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
Comment 8 David REVOY 2018-06-22 09:14:13 UTC
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.
Comment 9 wolthera 2018-06-27 15:51:04 UTC
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
Comment 10 Halla Rempt 2018-06-27 16:47:16 UTC
Could it be a localisation issue? Deevad, is your system set to French?
Comment 11 David REVOY 2018-06-27 16:54:17 UTC
@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...
Comment 12 David REVOY 2018-06-27 17:20:12 UTC
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.
Comment 13 Halla Rempt 2019-05-02 10:23:29 UTC
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
Comment 14 David REVOY 2019-05-02 10:52:14 UTC
Thank you very much Boys!
Comment 15 David REVOY 2019-05-02 10:53:34 UTC
s/Boys/Boud 
(autocorrect issue on smartphone 's keyboard, sorry)