When I select the Logarithmic Scale checkbox for a histogram display, does anything other than the histogram get rescaled? Specifically:
Is the vertical axis also rescaled? If not, then it seems that the 45 degree line for the identity transformation should no longer be a straight line.
When I click on the histogram to set SP for GHS transformation (or BP for linear) the x value appears to be still using a linear scale, correct?
The transformation curve also appears to be the same as for the linear scale - also correct?
I’m surprised if all that is true, since I would have expected all the curves and selection points to scale along with the histogram, since we’re using it for reference. Am I missing something?
(BTW - I love the GHS stretch option. I’m far from having mastered it, but the flexibility and power of the transformation are clear.)
I had expected a quick answer to this question, assuming that it would be common knowledge to experienced users or any developers of Siril. Maybe not (?).
In any case, while I’ve been waiting, I think I figured it out. All along I’ve been assuming that the logarithmic scale applies to the horizontal axis, which wouldn’t be unusual for data that spans several orders of magnitude in that direction. I’ve come to realize that the rescaling is actually for the vertical axis of the histogram, for similar reasons. Since the horizontal axis doesn’t actually change, that explains why the SP can be selected by clicking the plot in the same location, whether in linear or logarithmic mode.
That answers the other questions as well, since the transformation curves really refer to a different vertical axis - brightness rather than pixel count - so they don’t change when the vertical scale is changed for the histogram.
Of course, the question now is why it took me so long to realize all this. The first answer is simply that it doesn’t seem to be mentioned explicitly in the documentation, possibly because it seemed obvious (?). The other reason is that there are no axis markings on the plot. That’s a bit of a peeve for me.
Is this because the number of users who need axis labels and units wouldn’t justify the GUI real estate? Maybe that’s so, but I’ll bet I’m not the only one who would like to see the typical log scale markings to make it clear where the scale is logarithmic. I also wouldn’t mind a second vertical axis for the transforms, but I suspect that would be asking too much in an already cramped GUI panel. Generally, though, I just like numbers so that I know what the plot lines indicate.
Hi, dev here. I don’t often read pixls.us so I hadn’t seen your post till just now. Yes, as you figured out, the logarithmic scale applies to the vertical axis; it helps to visualise the small number of pixels well above the histogram peak so that when applying a histogram or GHT stretch it’s more obvious when you’re driving pixels into or very close to clipping.
The transformation curves don’t obey the logarithmic setting: a no-effect transformation will always just look like a straight line, and then as you change the transformation parameters the shape of the curve changes.
I didn’t create the histogram view originally, but I did extend it when adding GHT. I think the lack of labels and units is probably because of UI space - we try to ensure Siril works for users with relatively small displays and GTK3 doesn’t make that very easy as it gives us some issues around resizing of widgets and dialogs.
Changing the grid to a representative log grid when in log mode is an interesting idea. It wouldn’t work as a real grid where the lines meant anything, as the histogram auto-scales every time it updates so “real” log grid lines would jump about all over the place as the number of pixels in each histogram bin changed. But as a visual cue that the histogram is in log y-axis mode it might be OK.
I’ll open an issue on gitlab, but in all honesty I think it’s probably relatively low priority compared with other functionality we want to add, and doing a proper review of how the UI is presented probably can’t happen while we’re still using GTK3.