Given that you can already do that with the over/under values I suspect we
just need better documentation of this feature.
Extending the colormappable family of things to take over/under/bad colors
as input might also be a nice convince to add.
Tom
···
On Mon, Jun 4, 2018 at 6:19 PM Juan Nunez-Iglesias <jni.soma at gmail.com> wrote:
Hi,
Would a PR to add HiLo to Matplotlib be welcome? It seems very useful in
general and especially in scientific data analysis, see e.g.
Go West! (…ern) | Post-Acquisition
See also this StackOverflow question:
python 3.x - How to achieve the Fiji "HiLo" colormap in matplotlib image plots, to mark under and overexposed pixels - Stack Overflow
Juan.
_______________________________________________
Matplotlib-users mailing list
Matplotlib-users at python.org
Matplotlib-users Info Page
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/matplotlib-users/attachments/20180604/8f7b21ad/attachment.html>
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...
URL: <http://mail.python.org/pipermail/matplotlib-users/attachments/20180605/a240d26c/attachment.html>
···
On Tue, Jun 5, 2018, at 10:37 AM, Thomas Caswell wrote:
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.
Tom
···
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...
URL: <http://mail.python.org/pipermail/matplotlib-users/attachments/20180604/d9fd5aa0/attachment.html>
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.
Ah. Yes this is totally terrible. Very good point. =) So colormaps are
segmented to e.g. 256 by default, rather than all the input values?
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.
That's not too bad I guess. =)
So, to rephrase your position: a PR to the examples gallery would be
welcome? =P
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/matplotlib-users/attachments/20180605/a10c9ca4/attachment-0001.html>
···
On Tue, Jun 5, 2018, at 11:53 AM, Thomas Caswell wrote:
So colormaps are segmented to e.g. 256 by default, rather than all the
input values?
Yes, because colormap objects may be re-used with many data sets so can't
know anything about the input values ahead of time (They don't even get to
see the raw data as it has been through a Normalize object first).
Yes, a PR with that example would be welcome.
Tom
···
On Mon, Jun 4, 2018 at 8:58 PM Juan Nunez-Iglesias <jni.soma at gmail.com> wrote:
On Tue, Jun 5, 2018, at 11:53 AM, Thomas Caswell wrote:
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.
Ah. Yes this is totally terrible. Very good point. =) So colormaps are
segmented to e.g. 256 by default, rather than all the input values?
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.
That's not too bad I guess. =)
So, to rephrase your position: a PR to the examples gallery would be
welcome? =P
_______________________________________________
Matplotlib-users mailing list
Matplotlib-users at python.org
Matplotlib-users Info Page
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/matplotlib-users/attachments/20180610/b5c1b0a1/attachment.html>