/usr/lib/python3.10/site-packages/matplotlib/colors.py:730: DeprecationWarning: NumPy will stop allowing conversion of out-of-bound Python integers to integer arrays. The conversion of 257 to uint8 will fail in the future.
For the old behavior, usually:
np.array(value).astype(dtype)`
will give the desired result (the cast overflows).
xa[xa > self.N - 1] = self._i_over
/usr/lib/python3.10/site-packages/matplotlib/colors.py:731: DeprecationWarning: NumPy will stop allowing conversion of out-of-bound Python integers to integer arrays. The conversion of 256 to uint8 will fail in the future.
For the old behavior, usually:
np.array(value).astype(dtype)`
will give the desired result (the cast overflows).
xa[xa < 0] = self._i_under
/usr/lib/python3.10/site-packages/matplotlib/colors.py:732: DeprecationWarning: NumPy will stop allowing conversion of out-of-bound Python integers to integer arrays. The conversion of 258 to uint8 will fail in the future.
For the old behavior, usually:
np.array(value).astype(dtype)`
will give the desired result (the cast overflows).
xa[mask_bad] = self._i_bad
Sorry, forgot to mention that you need to enable the warnings during normal execution, e.g., python -W always <file>.py. In my case, the warnings are issued during pytest run which seems to activate these warnings by default.
I think that one way forward would be to check the type of xa for int/uint and in that case take modulo the maximum value for self._i_over etc. This is basically what happens now anyway, but we need to do it explicitly rather than relying on numpy doing it. (I cannot really see how this makes sense from a color perspective, but we will at least keep the current behavior.)
I think this is exposing a real bug that we need to promote the input data to be bigger than uint8. What we are doing here is buildin a lookup up table, the first N entries are for for values into the actually color map and then the next 3 entries are the special cases for over/under/bad so xa needs to be big enough to hold self.N + 2 as values.
I don't know if this is a bigger bug or not, but I would like us to have fixed any deprecation warnings from dependencies before 3.7 is out (or if necessary a quick 3.7.1.)
Activity
dstansby commented on Jan 1, 2023
Thanks for the report! Unfortunately I can't reproduce this. What version of numpy are you using when the warning appears?
sergiud commented on Jan 1, 2023
Sorry, forgot to mention that you need to enable the warnings during normal execution, e.g., python -W always <file>.py. In my case, the warnings are issued during pytest run which seems to activate these warnings by default.
As for the NumPy version, I'm running
dstansby commented on Jan 1, 2023
Thanks, I can now reproduce 😄
oscargus commented on Jan 10, 2023
The problem is that there are three more values, that are by default out of range in this case, to note specific cases:
matplotlib/lib/matplotlib/colors.py
Lines 673 to 675 in 8d2329a
(N = 256 by default)
These are then assigned to out-of-range and masked/bad values here:
matplotlib/lib/matplotlib/colors.py
Lines 730 to 732 in 8d2329a
which now raises a deprecation warning.
I think that one way forward would be to check the type of xa for int/uint and in that case take modulo the maximum value for self._i_over etc. This is basically what happens now anyway, but we need to do it explicitly rather than relying on numpy doing it. (I cannot really see how this makes sense from a color perspective, but we will at least keep the current behavior.)
tacaswell commented on Jan 11, 2023
I think this is exposing a real bug that we need to promote the input data to be bigger than uint8. What we are doing here is buildin a lookup up table, the first N entries are for for values into the actually color map and then the next 3 entries are the special cases for over/under/bad so xa needs to be big enough to hold self.N + 2 as values.
QuLogic commented on Jan 13, 2023
I don't know if this is a bigger bug or not, but I would like us to have fixed any deprecation warnings from dependencies before 3.7 is out (or if necessary a quick 3.7.1.)
dangersniru commented on May 25, 2024
Change it to (np.array()).astype(np.int8) helps.