GNOME Bugzilla – Bug 750940
Make the histogram (dialog, Levels, Curves, etc) default to show RGB instead of Value
Last modified: 2018-05-24 15:22:08 UTC
Created attachment 305244 [details] [review]
Patch to make the histogram dialog default to RGB instead of Value
My preference is to see the RGB histogram in the histogram dialog. But the histogram dialog resets to the Value histogram just about every time anything is done to the image.
The Value histogram is not terribly useful. Even seeing the Luminance histogram (https://bugzilla.gnome.org/show_bug.cgi?id=109161) is not as useful for photographic editing as seeing the RGB histogram, because the Luminance histogram doesn't show individual channel values, and so adjustments using the Luminance histogram can easily cause unintended channel clipping.
The attached patch makes the RGB histogram the default histogram for the histogram dialog.
An alternative (or nice addition) to making the RGB histogram the default histogram would be if the user could choose the default histogram in the Preferences dialog (or even in the histogram dialog UI itself, which might be more convenient to change if the user's editing needs change from one image to the next).
This patch has the unanticipated but very nice side-effect of making the initially displayed histogram for the Levels dialog be RGB instead of Value, thus allowing to set the end-points while seeing exactly which channels might be clipped. Unfortunately the Levels RGB histogram is replaced with the Value histogram as soon as the user goes to, say, the Red channel, and then back to the Value channel. And even more unfortunately the Curves dialog still shows the Value channel instead of the RGB channels.
It would be most helpful to be able to see all three channels, perhaps with a Luminance backdrop (when the Luminance channel is added to the histogram), while making Levels and Curves changes.
Created attachment 305245 [details]
Picture of the RGB histogram in Levels
Seeing the RGB histogram when using Levels and Curves to adjust all three channels at once by the same amount (which is what the Value channel adjustments actually do) is much more useful than seeing the Value channel histogram. Seeing the RGB channels allows you to see whether and by how much the adjustment might be clipping any of the individual channels.
That's IMO a nice idea worth considering, but we should first look
into bug 109161, I also commented there and asked Thomas to change his
(In reply to Michael Natterer from comment #2)
> That's IMO a nice idea worth considering, but we should first look
> into bug 109161, I also commented there and asked Thomas to change his
Patch of bug 109161 is pushed and the bug is closed for quite some time.
How does it block anything related to this bug ?
Mitch? What were you planning on doing with this one?
As Thomas notes, the deoendency is now closed.
The idea is good. But I don't like that in your implementation the mix of RGB results to black. I like more the implementation from darktable, where it is white. Have a look at the file I attached.
Created attachment 366803 [details]
-- GitLab Migration Automatic Message --
This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.
You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gimp/issues/699.