There are many ways to represent data. E.g., darktable has a waveform view.
Apple has docs on the common scopes of the video world. Wish RT, dt and PhotoRaw had as many options. 
I converted the 16bit uncompressed tif to a jpg and uploaded to Google Photos. Here is a link to that image.
Here’s the histogram from rawproc, my hack software. It scales the vertical axis to the max tone, sorta. FWIW…
Edit: It appears most of your blue is at the far right. I scrolled a bit to find the top, never got there. Oh, that’s probably what GIMP is doing to the blue channel, it’s scaling it to the biggest blue bucket, which pushes the rest of the data into the floor.
Got to thinking a little more about scaling. As ggbutcher I haven’t looked at any code either. I must also admit that I don’t fully comprehend what GIMP is doing that it calls “Logarithmic”. However, in it’s most basic form the histogram is trying to show how many of the total pixels are encoded with each of the possible (?tonal) values. I think that means that the histogram for each channel has the same number of values as does each other channel. Some kind of scaling is needed because the maximum number of pixels found with any particular value can vary quite widely based on the size and resolution of the image and the available space within which the histogram will be presented is limited. It would seem that this presents a somewhat different problem for the kind of presentation that displays several histograms simultaneously than for the case where only one histogram is displayed at a time.
In examples presented herein it is RT which is normally displaying several histograms within a single view. The graphics displayed herein for RT have removed the other channel in each instance in order to accentuate the comparison to GIMP which only shows one histogram per view. Therefore if each of these separate (i.e., GIMP style) histograms are individually scaled it would become possible for most of the values, on the x-axis, to be represented by a small number or even none of the total pixels. However this should require that a large portion of the total pixels have one, or few, of the remaining values. In that, there should be a spike somewhere on the x-axis. This cannot be found in the Blue channel GIMP histogram shown above.
To make things even more confusing the linear GIMP histogram for the combined channels (i.e., “value” specified on GIMP’s color curves) shown below looks pretty much the same as the Blue channel histogram shown above.
That one looks very much like the RT one to me.
I just got done with a much more verbose way of making your point that a spike somewhere would explain how everything else is reduced to very minimal values. Problem is there is no spike on the GIMP blue channel histogram. I also upload another image which shows the combined histogram from GIMP. It is pretty hard to distinguish from the Blue channel histogram.
I recall when I wrote my histogram code I had to “scooch” the scale to fit in the window, specifically to include the upper and lower clipping.
The bars are there. Just incredibly faint and hard to see. I suggest that you make a request to the GIMP devs to make the histogram more visible.
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?
You can experiment with G’MIC:
gmic 4Comparison.jpg split c histogram 256,0,255 append c cut 0,400000 display_graph 1024,512,3 -o histogram1.png
gmic 4Comparison.jpg display_histogram 1024,512,256,0,255,1,"cut(i\,0\,400000)" -o histogram2.png
1 Like
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?
I also use PWP 
The gaps between the vertical lines mean that there are no pixels with those values.
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
1 Like
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…