[hist] Implement AutoZoom of TH1/TH2/TH3/TAxis to filled range

[ferdymercury]

This Pull request:

Changes or fixes:

Fixes #14538

Checklist:

• tested changes locally
• updated the docs (if necessary)

[linev]

Great!

Features was implemented long-long time ago in JSROOT,
now it is time to have it in ROOT.

But several changes are required:

• exclude loop repetition in TH1::GetRangeOfFilledWeights
• if TH1::AutoZoom is invoked, it only should affect that histogram and not change zooming in all other histograms in the pad
• same true for TAxis::AutoZoom - it only should change properties of this axis and not all histograms in the pad
• but must be checked with superimposed histograms, THStack, TMultiGraph - they all can have side effects
• fix failures with roottest

[github-actions]

Test Results

    19 files      19 suites   3d 13h 46m 21s ⏱️
 3 662 tests  3 615 ✅ 0 💤 47 ❌
68 172 runs  68 120 ✅ 5 💤 47 ❌

For more details on these failures, see this check.

Results for commit 06a128a.

♻️ This comment has been updated with latest results.

[ferdymercury]

• if TH1::AutoZoom is invoked, it only should affect that histogram and not change zooming in all other histograms in the pad

This is already the behavior 'most of the time'. Only if DrawFrame was called before, the multi-analysis is run.
I was trying to mimick what Unzoom was doing, why should it be different?

[linev]

Only if DrawFrame was called before, the multi-analysis is run.

DrawFrame is special use-case and not used with THStack or TMultiGraph painting.
And Unzoom() can behave differently as AutoZoom().

[linev]

We need to wait with this PR until roottest merged into ROOT master.
Then one can sync all changes in one PR.

[ferdymercury]

I thought it was already merged, and I had rebased and synced into one.

[linev]

I thought it was already merged

Yes, now I also see roottest in main repository. Things changing very fast!

[linev]

I tried your code and have several more comments.

1. For 1-D histogram with few entries TH1::AutoZoom() changes zooming for Y axis which is not nice.
2. Selected range is exact position of the non-zero bins. If peak is very sharp and has just single bin width - produced result is unusable. One need some default margins on the left and right side of the peak.
3. If there are several peaks - AutoZoom always show all peaks and not most significant one. Also if histogram already pre-zoomed to some range - peak should be searched in this range.

See my simple demo.
autozoom.C.txt

With THStack method does not work.

With superimposed histograms AutoZoom works only when first histogram is selected - for all others histogram method has no effect. At the same time Unzoom works for all histograms. Here correspondent demo:

autozoom_same.C.txt

[ferdymercury]

1. For 1-D histogram with few entries TH1::AutoZoom() changes zooming for Y axis which is not nice.

I guess that's a feature of "TH1::UnZoom" that is also not nice, that could be handled in a separate PR ?

2. Selected range is exact position of the non-zero bins. If peak is very sharp and has just single bin width - produced result is unusable. One need some default margins on the left and right side of the peak.

I have implemented this now. It could be modified to accept a relative percentage rather than a fixed number of bins if wanted.

3. If there are several peaks - AutoZoom always show all peaks and not most significant one.

I do not understand what you mean. I am proposing AutoZoom to show all peaks, rather than the most significant.

3. Also if histogram already pre-zoomed to some range - peak should be searched in this range.

I kind of disagree, sometimes I like to zoom in to see a specific thing, and then AutoZoom to zoom out to the filled range. Maybe ZoomToFit is a better word for the function??

With superimposed histograms AutoZoom works only when first histogram is selected - for all others histogram method has no effect.

I had made a mistake. Is now fixed, thanks for finding out. You need though to click on the x-axis and click on AutoZoomAll, not AutoZoom. An equivalent function can be created in the TH1::AutoZoomAll if you think it's worth.

With THStack method does not work.

Support has been added now, via TAxis::AutozoomAll.

[linev]

Still, AutoZoom on simple TH1 with few entries changes Y-zoom,
And current range is not taken into account when search for the range.

[ferdymercury]

Still, AutoZoom on simple TH1 with few entries changes Y-zoom

But Unzoom does the same, it's changing that too. It's zooming in rather than out.

And current range is not taken into account when search for the range.

Yes, but I argue that that's intended. Autozoom in matplotlib works also like that.

[linev]

But Unzoom does the same, it's changing that too. It's zooming in rather than out.

Then one need to fix Unzoom too. It is not nice behavior.

Autozoom in matplotlib works also like that.

Use-case is simple. One makes approx zooming with mouse and then call method to get peak fully displayed.
Therefore behavior of matplotlib is not best approach here.

[ferdymercury]

Then one need to fix Unzoom too. It is not nice behavior.

Last commit tries to fix that.

[dpiparo]

@couet @linev is this ready to be merged?

[linev]

@dpiparo No, there several issues with the PR.

[ferdymercury]

In my opinion this is ready to be merged.

The remaining comments by @linev are debatable from my point of view. For example, I disagree with the feature that zooms to a visible peak even if there might be higher peaks outside the currently visible range, since it goes against the typical behavior of eg matplotlib. If this is really wanted, then this should be a separate function that could be implemented in a separate PR. It could be called Smartzoom insted of Autozoom.

Besides, that SmartZoom solution is overcomplicated from the coding point of view, and hard to maintain, we need to pass as argument a vector with all preset zoom ranges for all dimensions, as well as if include or not overflow, etc etc, ie bugprone for many corner cases, if we have 5 histograms on top of each other, etc. I would propose to keep it simple as is and not delay this feature any X more years. No one is using it now, so if we introduce it and someone complains that why don't we have a new feature doing the extra recursive zoom, then we could think if it's worth to spend the time in implementing it.