Bug 421687 - Color change shortcuts glitch when changing hue or making it darker and lighter
Summary: Color change shortcuts glitch when changing hue or making it darker and lighter
Status: CONFIRMED
Alias: None
Product: krita
Classification: Applications
Component: Shortcuts and Canvas Input Settings (other bugs)
Version First Reported In: 5.2.9
Platform: Appimage Linux
: NOR normal
Target Milestone: ---
Assignee: Krita Bugs
URL:
Keywords:
: 422955 (view as bug list)
Depends on:
Blocks:
 
Reported: 2020-05-17 19:55 UTC by Sonia
Modified: 2025-04-29 18:59 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments
recorded glitch for color change (692.04 KB, image/gif)
2020-05-17 20:01 UTC, Sonia
Details
Another recorded change for color change glitch (100.47 KB, image/gif)
2020-05-17 20:02 UTC, Sonia
Details
color hue change glitch (1.55 MB, image/gif)
2020-05-17 20:06 UTC, Sonia
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Sonia 2020-05-17 19:55:31 UTC
SUMMARY


STEPS TO REPRODUCE
1. shortcuts for "Make color darker" and "make color lighter" ( after a few clicks) slowly end up in selecting just greys from white to black. It does not return the color back to its original hue  when pressing shortcuts. Color keeps moving around the triangle color selector area.
2. Shift brush color hue clockwise and anticlockwise also does the same thing. It slowly shifts the hue to greys and then black and white and goes back and forth from black to white and does not stay in the exact same place as the original hue, with only hue shift.
3. 

OBSERVED RESULT


EXPECTED RESULT
1.Specific color should stay in exact same position regardless of hue change, when it is shifted clockwise or anticlockwise on the color wheel.
2.Make brush color or darker should return the value to its original value or tint as many times as required and not get stuck between greys.
3. 

SOFTWARE/OS VERSIONS
Windows: Windows 10
macOS: 
Linux/KDE Plasma: 
(available in About System)
KDE Plasma Version: 
KDE Frameworks Version: 
Qt Version: 

ADDITIONAL INFORMATION
Comment 1 Sonia 2020-05-17 20:01:55 UTC
Created attachment 128551 [details]
recorded glitch for color change
Comment 2 Sonia 2020-05-17 20:02:24 UTC
Created attachment 128552 [details]
Another recorded change for color change glitch
Comment 3 Sonia 2020-05-17 20:05:17 UTC
Comment on attachment 128552 [details]
Another recorded change for color change glitch

Sorry this one did not record properly, uploading a new one
Comment 4 Sonia 2020-05-17 20:06:38 UTC
Created attachment 128553 [details]
color hue change glitch
Comment 5 Ahab Greybeard 2020-05-22 13:37:27 UTC
I can confirm this for the 4.3.0 beta-1 appimage and the 4.2.9 appimage.

The darker/lighter shift is quite good at maintaining hue information until the resulting colour is very dark or very light. This may be unavoidable.

For hue shift, the saturation/value jumps around a lot but does go back along the same 'path' in the reverse direction.
Again, if the resulting colour is dark or light enough it just stays on the grey edge.

For hue shift, is the jumping around inside the SV triangle an attempt at maintaining some 'perceptual' value?

Setting to CONFIRMED
Comment 6 Vitamorus 2025-04-29 18:26:55 UTC
Re-confirmed for 5.2.9.

Once the color reaches pure black or pure white, the system loses track of the original saturation. 

The hue-shifting bug I would assume the system attempts to preserve the relative lightness of the color while shifting the hue. I think it's a neat idea, but I can understand that a lot of people don't expect that behaviour. There is however a bug where if you keep holding the shortcut for shifting the hue it will keep shifting towards black (I'm guessing the lightness value is being rounded down in some way).
Comment 7 Vitamorus 2025-04-29 18:59:47 UTC
*** Bug 422955 has been marked as a duplicate of this bug. ***