Is the meaning of “scooch” something like “squeeze”? Would squeezing the scale mean that the ends points went out of view?
According to both GIMP and RT there is very little clipping in this image. RT puts a value on it which in this case is less than .02%. I’m thinking that clipping would have the affect of allowing pixels that should not be the same ending up in the same position on either the extreme left or right end the histogram. Could also be both ends.
When it comes to useful information knowing about such spikes on either end would seem to me to be much more important than anything you might learn about the sparsely distributed other pixels. That might mean show the spikes no matter what that does to the rest of the histogram.
It’s a technical term.
What it means for the histogram is that I have to horizontally scale the histogram graphic to the window dimensions minus a pixel or two, I forget now what it is. That way, those vertical ascents at the ends don’t end up in the window borders.
Can’t tell from the JPEG, but you have a lot of blue in the sky that falls in the range 253-255. From the raw, RT is in a better position to evaluate the clipping done for the output, so I’d put stock in that .02%.
This is exactly why I ‘scooched’ my histogram scaling.
Just checked my histogram scaling, and I subtract 6 from the window width and height numbers before I set the scaling. IIRC, it was a ‘try, nope, try, nope, try, closer, try, Yes!’ thing…
Yes, I could see those very slight bars on the far right once I looked closely enough. However, based on the explanation discussed herein it looks like a very large portion of the pixels should appear on the far right. In that, the only reason for the values shown to appear so low on the histogram is the need to show something that uses the whole height of the histogram.
Is it possible, that such is covered by the grid line? That would seem to me to be a plausible explanation but not a good solution. I found a histogram that does (see subsequent reply if interested).
I have an editing program, called Picture Window Pro, that I’ve only ever used for printing because it is more capable than other things I’ve found for printing more than one image on a single sheet of paper. However, it can produce histograms and it seems to show just what you’ve concluded. In that, on the far right it goes off the chart vertically. While not terribly conspicuous because it is so thin it is there and is consistent with the rest of the histogram.
I’m thinking that GIMP should at least match this one. What about you?
Thanks! It looks like this isn’t really meant for Windows systems but I did get it working and, thanks to your offering the commands, was able to produce the histograms you showed pretty easily. This might come in handy sometime but it’s a bit cumbersome for making part of a regular workflow.
What may be more interesting is that in the process I also got the G’MIC plugins working on GIMP. Now all I need is 48 hour days.
By the way, I also found another pretty old program I had previously installed on another system which is capable of making histograms. Below is what ArcSoft PhotoStudio 6 produces with its’ “Levels” tool (e.g., it seems it doesn’t do curves) which I’d say is very nice. This is an even better idea for what GIMP should/could do. It has everything and from my way of seeing it really tells you what you want to know.
By the way, may I assume that when doing histograms for images that have 16 bits of color depth the algorithms work basically the same but operate on only the high order 8 bits?
I do notice that there is a different appearance for 8 bit and 16 bit histograms in GIMP where the 16 bit images display vertical lines rather than filling in the space. Might this be intended to mean that there are what I might call in-between color values that have not been separately analyzed?
Though not related to open source, I find this very interesting. Some of us old guys know Lotus 1-2-3, I guess. PWP was also written by the one who wrote 1-2-3
Right now, my histograms ‘bucket’ 256 values, even though the working image is 32-bit float. I’ve messed with ‘more precise’ histograms, but the processing to display them is onerous, and it gets lost in the scaling to the little window. If I want a more precise histogram, I pull out G’MIC, even on Windows…
@ggbutcher It depends on how the values are distributed. I rather have a smooth histogram than one with a million peaks. The point of a histogram in processing is to see trends and patterns.
Yes, most definitely. In my 256-bucket histogram, when you start to get 0-dropouts, you know the data has been over-manipulated. Or, you started with a JPEG image…
Discussion herein seems suggest that the nearly disappearing histograms produced by GIMP (i.e., for blue and combined channels) is the result of the choice of scale for the vertical axis. The idea being that the existence of a very large number of pixels for a discreet x value depress the height of everything else on the graphic display.
However, this should mean that the histograms shown herein that display all three color channels at the same time (I.e., as in the case of RT and G’MIC) could only appear as they do if a different scale is used for each color channel. The G’MIC histograms above appear to show the vertical scale in units that I presume to be the number of pixels. This creates a definite impression that the same scale applies to all 3 color channels. If so for G’MIC why not for GIMP? What is GIMP doing differently that causes such dramatic depression of essentially all y values?
The difficulty Gimp 2.10 has with histograms in the “curves” window is that they are shown as gray on a gray background with a gray grid. This crafty colour-scheme is designed to weed out those of us with less than perfect eyesight.
With the “dark” theme, the gray histogram in the “curves” window is slightly lighter than the background and slightly darker than the grid, which is drawn before the histogram. When we have highlight clipping, the grid on the right side is dark where the histogram has overwritten the grid.
By contrast, the histogram in the “levels” window is white, or at least much lighter than both background and grid, so it is easier to see.
The “light” theme shows the curves histogram slightly lighter than the grid, and we see in the screenshots from @ajax in this thread. We can see, but only by looking very carefully, that blue has clipped massively.
Other histograms shown above have histograms sensibly shown in colours. If a designer wants to make them less obtrusive, the colour could be blended 50% with the background gray.
[rant]I remember, around 1980, when computer screens didn’t have colour. We had different shades of gray, including black and white, and had to make do. Modern computers have colour screens but some designers hate to use colours and also hate both black and white, and especially hate the high contrast of black and white together. They adore having various different shades of gray things on gray backgrounds, with low contrast.
Microsoft Windows has a “high contrast” setting that sometimes writes black characters on a black background. Grrrrrrr.[/rant]
Since we’re 35 posts into this topic, I hope one of you who finds issue with GIMP’s histograms has actually filed an enhancement request in the proper place: https://gitlab.gnome.org/GNOME/gimp/issues
This sounds like a good idea to me. However, I don’t have a gitlab account and feel like others of you may be better choices for who does it. For example, is it possible that some of you have done this before.
My summary of the state of this discussion would go as follows:
The idea that scaling suppresses the histogram to the point it essentially becomes invisible is something I’d classify as a serious problem.
The histogram needs to reveal values at the extreme light & dark end of the x-axis especially when there are more of them than any other value.
Insofar as all the themes use various shades of gray it would be helpful if a different color (e.g., Red, Green, Blue & something) were used for the histogram.
Please add what I may have left out.
Something else which, I don’t think, was included in this discussion but appears to be done by other software products is the idea of displaying a continually updated histogram in a separate window or portion thereof. My experience is limited but it looks to me like maintaining an awareness of the current state of the histogram can be very helpful.
