Gradient map fix suggestion

Hello, everybody knows that gradient map tool works slowly in Krita and that gets in the way of actually using it.

However it seems that the nearest and dither algorithms work really snappy and almost immediately. So what if Krita used the nearest algorithm to make a quick and dirty preview of what it’s going to look like and then updating in the “BLEND” mode to give me the quality result? Picture related, this was generated in real time almost immediatelly.

What I’m suggesting is:
-user tweaks a gradient map for the image
-Krita immediately samples like 10 points from the gradient
-generates a quick preview image with the “nearest algorithm”
-user knows what the image is going to look like and can see what further tweaks are needed

Currently the gradient maps take 10 to 30 seconds to update on a modern overclocked machine and that just breaks the WYSIWYG workflow. Having to spend entire minutes to tweak a single gradient for a part of an image is a real hindrance.

1 Like

Well, I hadn’t noticed that the gradient map filter was slow, nor that somehow the gradient selector dropdown had broken in 4.3.0 :-(, but I’ve taken a a look at what takes up most time and that’s the actual retrieval of the color from the gradient. And I think it should be very possible to optimize that. There’s no reason to ask for the colorspace over and again… Here’s a nice cachegrind map:

1 Like

Great to hear that there’s hope for improvement!

I’ve created a bug: https://bugs.kde.org/show_bug.cgi?id=423273 – I tried to fix it just now, but it needs more thinking…

3 Likes

(for boud) Maybe this observation can help figuring it out? Quick tip on gradient map