Bug 313494

The problem was that UI was confusing.

If you set the curve to 50% on both ends, you get selected color for every hsv color sensor.
Check documentation here http://userbase.kde.org/File:Krita-tutorial4-IV.2-1.png

Labels will be changed to make it more intuitive to use.

http://www.davidrevoy.com/XYZ/2013-02-16_Krita-hue-saturation-value_bug_xvid.avi 
A HD video* ( 11MB ) Xvid 1600x900 to see the Bug in motion.

Description of video event : I trace a stroke on intro to show the basic Pixel Brush , with a pressure sensor affecting size only and the color I'll use. Then I go to the brush editor, and try to affect the Hue. The brush preview test area  fail with the bug ( 2 pure color ) , but the first stroke on canvas is OK ( surprise ) , then I return to the test area and fail again. So , I try other setup, changing ; and after that only failure for Saturation too ( showing RED and CYAN described on the bug report ) and also Value going from white to black without the color. 
In the test I try to switch also to openGL without success. It worked once. 
 
( * temp link, will expire in one or two month )

Git commit dae2629fa63bc0f54f1cc98a9fe4514c68c335cd by Lukáš Tvrdý.
Committed on 16/02/2013 at 20:12.
Pushed by lukast into branch 'master'.

HSV sensors: Improve UI intuitivness

Add labels to explain the change of color characteristics

o CW hue: Clock-wise change of hue (hue in hsv model is circle)
o CCW hue: Counter-clock wise change
o Lower/Higher value
o More/Less saturation

M  +30   -2    krita/plugins/paintops/libpaintop/kis_pressure_hsv_option.cpp

http://commits.kde.org/calligra/dae2629fa63bc0f54f1cc98a9fe4514c68c335cd

I can't reproduce that problem on the video...
Can you try on different system or with clean build of master or can you ask some Krita users to try to reproduce?

I tried to reproduce the problem in deevad's video on 32bit arch / intel graphics / Core i7
Not reproducible.

Reproduction attempted on:

- 64-bit Kubuntu 12.10 with Kubuntu-Backports PPA packages (including Krita 2.6)
- ATI Radeon graphics using the xorg-video-radeon drivers
- Intel Core i7-740QM 1.73GHz

Outcome: Unable to reproduce the bug.

- 64-bit Linux Mint KDE 12.10 
- Nvidia 310 proprietary
- Intel Core i7-870 2.93GHz

Vc is a requirement on my PC to build Krita, it won't build with a version older than master 7 february. 
Bug reproduced ( Clean install VC / clean install Krita from yesterday. )

Btw, for Vc, you should use the 0.7 branch, not master.

Sorry for bothering. But Scatter parameter is also in absolute values(pixels). But it should be relative to brush size.
Here is my bug report with a screenshot: https://bugs.kde.org/show_bug.cgi?id=320488

I'd like to report I have the same brush behaviour shown by David Revoy's video in comment #2:

- "Value" seems to completely ignore the hue component of active colour and paints only a scale of grey
- "Hue" seems to go only from the active colour to neutral grey, without anything inbetween.

Some system specification:
- Linux Mint 15 MATE on VirtualBox 4.2.12 (OSX 10.6.8, MacBook5,2, 2 GHz Intel Core 2 Duo, Nvidia GeForce 9400M)
- Open source graphic drivers
- Krita 2.8 prealpha installed from Krita Lime PPA, last updated 2013-06-07, OpenGL option inactive

I checked a prior version on a different system and the brush shows the expected behaviour (as in documentation LukasT linked in comment #1):
- Linux Kubuntu Raring on VirtualBox (same as above)
- Open source graphic drivers
- Krita 2.6.3 installed from Kubuntu repositories, OpenGL option inactive

Let me know if I have to give other informations, or if there's some other step to check I'm not aware of.

*** Bug 321433 has been marked as a duplicate of this bug. ***

Two artists confirming the issues seems to me a proper confirmation indeed.

*** Bug 324876 has been marked as a duplicate of this bug. ***

*** Bug 325808 has been marked as a duplicate of this bug. ***

I can reproduce this on my machine against Vc 0.7.3 from the Arch Linux repositories. I'm going to take a crack at fixing it.

Awesome!

Alright, this evening I spend trying to figure out this bug. What I've found:

1. None of the three parameters adjust the current colour like they are supossed to. Instead, they overwrite them.
2. In this, the saturation is always set to 0 if not explicitely defined by the saturation sensor.
2b, so what you get is that you turn on Hue, but only paints grey because the saturation is 0.
3. Because the sensors are set up so that they can modify in both directions, we get wonderful things like Hue being -0.6, which doesn't work, so you only get the default value.
3b. Similarly, negative saturation in this case leads to the complementary colour.
4. Value is not Value. It's lightness. And, it's also the only one adjusting based on the current colour.

Which made me make a connection:
http://quickgit.kde.org/?p=calligra.git&a=commit&h=12737c6b353db80ca75a3ab819a5de3764a0e963

My suspicion is that these sensors are trying to adjust HSL coordinates while thinking they are HSV coordinates. However, I don't really understand pigment, and don't have a clue where to go from here.

This bug makes me sad.

After scourging pigment for the used options(namely kis_hsv_adjustments) I come to the conclusion it's not there.

My next stop was kis_brushop.cpp, lines 130 to 135.
There, we see the hsv options being put into a transform. Consequently, the transforms are applies to a color source, m_colorsource.

This reffers to kis_color_source line 76, applyColorTransformation
There, you see the hsv transformation being done, it has three parameters:
source pixel, destination pixel and nPixels, the later meaning how often this transformation is itterated(?).
Anyhow, the last parameter is set to 1. When you set it to 0 the HSV options don't work at all, because duh, there's 0 itterations of the color transformation being done.

So, I debugged the pixel being input with the following:
qDebug()<<m_color->toQColor();

This showed that regularly, if you had H, S and V active, the pixel color being input was black.
On other places in the file, it showed that m_color was being create by, amongst others, the mix parameter. So turning that on(while deactivating the sensors), m_color started returning a color other than black.

It even started updating said pixel.

However.
It didn't update the color being painted.

Which leaves us with the confusing situation where:
*We have found the right color transformation, deactivating it turn off the results.
*The pixel transformed at HSV adjustment is NOT m_color, despite it being m_color that is specified.
*The color is also sent to the active foreground color, while not being m_color.

Another weird thing: Value is not similar to lightness. No, activate hue and saturation, but turn off sensor input: Now paint with yellow, and then turn the hue to blue: The color becomes much darker, even though HSV wise it shouldn't change at all.

This bug is breaking me.

Fixed in: http://quickgit.kde.org/?p=calligra.git&a=commit&h=a715bc4010159c6fcc5e3abee9e53fc4b4da32e0
Please test :)