Hi Tom, On Fri, Jul 23, 2021, at 17:57, Thomas Caswell wrote:
See around https://github.com/matplotlib/matplotlib/blob/88f53b12e1443a9ae046ee55d1f1d6... and https://github.com/matplotlib/matplotlib/pull/17636, https://github.com/matplotlib/matplotlib/pull/10613, https://github.com/matplotlib/matplotlib/pull/10133
Where the issues tend to show up is if you have enough dynamic range that the small end is less than difference between adjacent representable numbers at the high end e.g.
In [5]: 1e16 == (1e16 + 1) Out[5]: True
This issue would crop up if you had, e.g., uint64 images utilizing the full range. We don't support uint64 images, and uint32 is OK still on this front if you use `float64` for calculations.
In some cases the scaling / unscaling does not work out the way you wish it would. While it is possible that the issues we are having are related to what we are doing with the results, forcing to [0, 1] restricts you to ~15 orders of magnitude on the whole image which seems not ideal. While it may not be common, that Matplotlib got those bug reports says we do have users with such extreme dynamic range in the community!
15 orders of magnitude is enormous! Note that all our floating point operations internally currently happen with float64 anyway—and this is pretty much the best you can do here. The other issue you mention is due to interpolation that sometimes goes outside the desired range; but this is an expected artifact of interpolation (which we typically have the `clip` flag for). To be clear, I'm trying to get a the underlying issues here and identify them; not to dismiss your concerns! Best regards, Stéfan