After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 331782 - Curves tool in Value histogram channel changes hues too
Curves tool in Value histogram channel changes hues too
Status: RESOLVED DUPLICATE of bug 432933
Product: GIMP
Classification: Other
Component: Tools
2.3.x
Other All
: Normal minor
: ---
Assigned To: GIMP Bugs
GIMP Bugs
Depends on:
Blocks:
 
 
Reported: 2006-02-19 15:11 UTC by Stephane Chauveau
Modified: 2017-01-16 09:22 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Prelimnary patch against trunk to address this issue (6.68 KB, patch)
2007-05-05 07:16 UTC, Mukund Sivaraman
reviewed Details | Review

Description Stephane Chauveau 2006-02-19 15:11:09 UTC
Please describe the problem:
I always used the Value curve in the Curve tool to adjust thee brightness and
constrast of my images and occasionally to adjust the shadows and highlights.
This is what a Value curve is supposed to do. I always though that the result
was sometimes strange but I was assuming that it was caused by rounding errors.  
However, I just discovered that in fact the so called Value curve is simply
equivalent to applying the same curve to the Red, Green and Blue channels. 
This is very different and that means that the Value curve is also changing the
Hue & Saturation. 

Steps to reproduce:
1. Fill an image with a bright orange color (Red=100% Green=50% Blue=0%)
2. Open the Curve tool and create a curve with 3 point (left, center, right)
3. Move the 3 points up and down

Actual results:
From the Orange color, you can obtain any color you want (Red, Blue, Green, ...)

Expected results:
The only thing a Curve tool should be able to produce are different levels
brightness of that orange color (from bright orange to black).


Does this happen every time?


Other information:
Comment 1 Albert Cahalan 2006-02-19 16:37:03 UTC
There are several different useful ways to have this behave. In an RGB coordinate space, you could remap along a line containing the starting color and...

a. passing through black
b. passing through white
c. parallel to the greyscale axis

Only the last option preserves saturation, but all three options have artistic value.

Even the existing behavior has uses.

Comment 2 Stephane Chauveau 2006-02-19 17:41:14 UTC
I understand that this behavior can be used in some cases but it should not be called "Value Curve". The documentation states "Value for luminosity and contrast" which is consistant with the definition of Value in HSV. 

I really do not see how any changes of luminosity or contrast could transform Orange into Green, Magenta or Blue. 

Anyone trying to adjust the luminosity or contrast with that curve is making a big mistake.







Comment 3 Mukund Sivaraman 2007-05-05 07:15:44 UTC
Renaming summary from "Value curve is in fact a R+G+B curve" to "Curves tool in Value histogram channel changes hues too".

Comment 4 Mukund Sivaraman 2007-05-05 07:16:56 UTC
Created attachment 87589 [details] [review]
Prelimnary patch against trunk to address this issue
Comment 5 Sven Neumann 2007-05-05 11:30:17 UTC
That looks nice and clean. Let's consider to use this for 2.4.
Comment 6 Mukund Sivaraman 2007-05-05 11:51:29 UTC
The fix has been committed in changeset 22418:

2007-05-05  Mukund Sivaraman  <muks@mukund.org>

        * app/base/gimplut.c
        * app/base/gimplut.h
        * app/tools/gimpcurvestool.c
        * app/tools/gimplevelstool.c: Fixed the value channel color
        correction in the curves and levels tools to only modify the
        value channel and not the hues. Fixes bug #331782.

Comment 7 Sven Neumann 2007-05-05 14:15:03 UTC
I am afraid we will have to revert this change. The problem is that now the state of the channel combo-box determines what algorithm is being used. The Curves and Levels tools however allow to make adjustments to different channels and the combination of all these adjustments is then applied. This does only work if the same code path is being taken, no matter what channel is selected in the UI. The change breaks loading of curves and levels and it also breaks the black/gray/white color pickers at the bottom of the Levels tool dialog which are supposed to change the R, G and B channels.

I don't think we can do any better than reverting this change and closing as NOTABUG.
Comment 8 Sven Neumann 2007-05-05 14:30:25 UTC
2007-05-05  Sven Neumann  <sven@gimp.org>

	* app/base/gimplut.[ch]
	* app/tools/gimpcurvestool.c
	* app/tools/gimplevelstool.c: reverted the changes done for bug
	#331782. See the bug report for an explanation.

The approach taken here cannot work. We could however try to improve the algorithm that modifies the LUTs for the RGB channels in response to changes in Value mode. 
Comment 9 Sven Neumann 2007-05-07 06:50:09 UTC
Apart from improvements to the current algorithm, this whole bug report basically just boils down to bug #432933.
Comment 10 Sven Neumann 2008-01-15 13:20:07 UTC

*** This bug has been marked as a duplicate of 432933 ***
Comment 11 Pierre-Antoine Champin 2017-01-16 09:22:26 UTC
As #432933 does not seem to be on its way to fixing, may I suggest a low hanging fruit for solving *this* bug in a simpler way: 

1. At the very least, fix section 5.8 of the documentation about "value", as it is very misleading (one thinks that it *is* the HSV value). Reuse the phrasing in section 5.7 which is much less misleading.

2. In addition, I think it would be better to rename the option "Value" in the combo-box (both in Curves and Levels) into something else, less confusing. Proposals: "RGB", "Red+Green+Blue", "All colour channels", "Combined value"...