Repository navigation
[Bug]: pcolormesh with gouraud shading not respecting bad color #27695
Description
Bug summary
The Quadmesh Demo shows how to set the "bad" color on a colormap to make the masked region yellow. However, it does not work in the current version.
Code for reproduction
https://matplotlib.org/3.8.2/gallery/images_contours_and_fields/quadmesh_demo.html
Actual outcome
Expected outcome
With v3.7.3 we had
https://matplotlib.org/3.7.3/gallery/images_contours_and_fields/quadmesh_demo.html
Additional information
If we remove shading='gouraud' from the pcolormesh call, the example works as expected.
Operating system
No response
Matplotlib Version
3.8.2 and main
Matplotlib Backend
No response
Python version
No response
Jupyter version
No response
Installation
None
Activity
ksunden commented on Jan 24, 2024
Likely related to #26072 (which was put in to fix #8802) It seems like the new behavior is the desired behavior for masked points, consistent with how pcolor works.
Does it produce the bad color if you change the value (rather than masking)?
rcomer commented on Jan 25, 2024
Ah OK. If the new behaviour is desired we should change the example then.
Sorry I’m not following what you mean by “change the value“.
QuLogic commented on Jan 25, 2024
I believe np.nan could also produce bad values, as opposed to masked arrays.
rcomer commented on Jan 25, 2024
If I add Zm = np.ma.filled(Zm, np.nan) before the plotting, I get the same result as when it was masked.
jpgarcia-ssec commented on Jan 16, 2025
This seems to be conntected to, in part, that collections.py's _MeshData._convert_mesh_to_triangles() grabs the array's mask, if one exists, and then sets all masked values to nan. Then later it uses isnan to create a mask, which then filters the return arrays to omit anything that was nan. This feels round-about and incorrect, since a nan that isn't masked shouldn't be automatically masked, it should be plotted using colormap's invalid color, as how it does with other shading methods. What probably should happen is the mask should be retrieved from the array (if it's masked) and be expanded to fit in place of the one it's making from isnan.
I've tested doing this, but it still doesn't get good results, which means I suspect something upstream is already doing something similar, because if i plot a mesh using a non-masked array, a masked array is still what arrives here, with all nan's being masked out yet again. If I have it just ignore the mask entirely, it restores it's old behavior of respecting the invalid color use with nans, but that just ignores the mask.
Using the array's mask as the mask instead of isnan, combined with figuring out what upstream is also masking nan values implicitly I suspect is a long-term fix, restoring invalid nan coloring while still allowing an array that is provided as masked to be masked.