Histograms: how are they displayed?

[BernardP]

I don't quite understand which scale (linear, log, etc.) is used to display the histograms. In these two examples, it is clear that the histogram is readable for a very low-contrast image, whereas in the second case, it is completely unreadable.
Is this configurable?

histo1.png

histo4.png

[xnview]

The histogram uses a linear scale, normalized to the highest value.
Please send me the 2 files, i'll try to improve it.

[BernardP]

I can provide you with two files, but this issue actually occurs in most cases, and you should be able to observe it yourself using many different images.
It is worth noting that Adobe software always uses a logarithmic scale, whereas Capture One uses a square-root scale.
Using a linear scale is inherently unsuitable and, in most instances, renders the histogram display unreadable.

[BernardP]

Here are two photos, along with the histograms as displayed in XnViewMP.

FXT10941 - copie.png

FXT11281 - copie.png

histo1.png

histo2.png

[jkm]

Something is definitely wrong. To make it more clear, here's a RGBL color-ramp that should produce a known result in the histo.

Spectrum-24bit-nodither.png

Here you can see the expected results as produced by Photoshop:

pshisto.PNG

And here is the XnViewMP histo; obviously wrong.

xnhisto.PNG

It looks like there is a problem with the normalization. The highest level in the histogram (0,0,0) only reaches halfway up the scale. All values are improperly compressed.

[xnview]

See issue for current status and some details.

[jkm]

Another thing to consider is high-key (bright) images.

Here is a reflective (CYMK) color-ramp as opposed to the emissive RBG I posted before:

Spectrum-CYMK-24bit.png

[xnview]

This problem is supposed to be fixed in XnView MP 1.12.3. Please check and confirm the bug fix here.

[jkm]

Yes, the new histogram functionality works well with these images.

The updated adaptive algorithm handles images like these much better, and the log and ignore extrema options can reveal even more detail for images like these.

Users can read more about the new histogram functionality in the documentation post.

[BernardP]

Yes, it works well now, but sometimes it gets clipped at the top, as shown in this image.

ecrete.png

[BernardP]

severely clipped here...

ecrete2.png

[xnview]

yes like photoshop

[BernardP]

So, yes, I agree, Photoshop has the same problem.

If it is adaptable, (and to do better than Photoshop!), it allows me to suggest another normalization mode (another formula).
This is the method used for example in astronomy to discriminate areas of low intensity (nebulae) that count other very bright (stars).

Here is the formula :

asinh1.png

Where k is the median of non-empty columns.

Here is a graphic view of different methods applied to the photo above:

asinh2.png

Best regards,

[jkm]

You're talking about doing an arcsinh stretch.

This approach was considered, but ultimately was not implemented, for a couple of reasons...

The old algorithm was obviously flawed and produced erroneous results. The goal was do do something better but still maintain the character of what the user was seeing. If the goal had merely been to produce a pretty histogram, an arcsinh stretch would have served, but it comes at a cost.

In XnViewMP, we are only trying to make the histo easier to read. The arcsinh stretch is designed to make more features visually distinguishable by modifying contrast; in other words, to change the appearance of the image.

If this method were applied to the histogram in XnViewMP, the histo would very much NOT match the image. It would make a high contrast image look like a much lower contrast image. Obviously log does that as well, but logarithmic scales are more widely understood, and it's only an option. The arcsinh stretched histo was certainly more "balanced" and readable, but could deviate from the image in ways that were misleading.

The approach taken was to preserve the appearance of a high-contrast histogram, but not so slavishly as before, to make it more readable. This is why peaks exceed the max on the chart. Photoshop made the same compromise, and so this approach also has the virtue of being familiar to users of Photoshop. It was also desirable to be in keeping with other photography related applications, as opposed to more specialized tools like Matlab or Pixinsight.

For something like an arcsinh stretch, there's no desire to add complexity by allowing the specification of a scaling factor. Your method is auto-scaling from the median, which simplifies, but it also stretches histos that don't need to be stretched.

An approach like this certainly could be added as an additional option, but I'm not sure it's suitable as a default for the reasons above.

Hopefully this helps...

[BernardP]

I agree that this might not be the best default option. However, just as one can currently choose a logarithmic scale, this option could be made available to allow users to see what lies within the truncated portion.
The fact that Photoshop doesn't handle it any better is of no concern to me—if I wanted to rely on Photoshop, I would use Bridge, not XnView...