I would not call it hacky, this is exactly what the over/under
functionality is for! It also fits the use-case of the blog post where
there is some knowledge that 0 and the max-int are invalid.
You are going to have a related issue with the color map. It is going to
take the top/bottom 1/Nth of the range to be marked as over/under which may
be _more_ that you want to grab. I also think it will grab asymmetrical
ranges for log scales.
For the API I am thinking something like
`im = ax.imshow(..., over_color='r', under_color='b')`
so that you can control that aspect of the color map from the user API.
On Mon, Jun 4, 2018 at 8:19 PM Juan Nunez-Iglesias <jni.soma at gmail.com> wrote:
On Tue, Jun 5, 2018, at 10:37 AM, Thomas Caswell wrote:
Given that you can already do that with the over/under values I suspect we
just need better documentation of this feature.
I would argue that over/under is hacky for this use-case, given that the
vmin and vmax have to be set not to the data but to something slightly less
than the data. For int as in the SO answer, it was relatively
straightforward. For float data now you have to set it to 0+epsilon,
1-epsilon, which isn't fun.
Extending the colormappable family of things to take over/under/bad colors
as input might also be a nice convince to add.
Can you elaborate on the interface you are envisioning for this?
-------------- next part --------------
An HTML attachment was scrubbed...