ENH: Allow RGB(A) arrays for pcolormesh #24619
Conversation
Allow a user to set the array values to explicit colors with RGB(A) values in the 3rd dimension.
5bfe4fe to
5804110
Compare
|
I'm honestly surprised that this was mostly removing / modifying input validation code. |
This is really helped out by moving the QuadMesh coordinates and array towards accepting 2D inputs and this being an extension of that. |
| C = C.ravel() | ||
| # convert to one dimensional array, except for 3D RGB(A) arrays | ||
| if C.ndim != 3: | ||
| C = C.ravel() |
There was a problem hiding this comment.
Why do 3-D arrays not need to be flattened at all?
There was a problem hiding this comment.
or conversely, why are we flattening 2-D arrays?
There was a problem hiding this comment.
Yes, I am not a fan of the flattening either... Allowing 2-D arrays is pretty new (only the last couple of releases), so everyone always used to have to flatten their arrays before getting/setting arrays. Unfortunately, that is baked into a few of our tests as expecting to pass a 2-D array in, and then calling mesh = plt.pcolormesh(z2d); mesh.get_array() == z2d.ravel(). I don't think we should be messing with people's arrays if they pass them in as 2D, but that may be too controversial to change at this point too...
There was a problem hiding this comment.
Why do 3-D arrays not need to be flattened at all?
Specifically for 3-D, we can not flatten them because the image RGB(A) color handling code will only handle the 3-D shapes of (M, N, [3 or 4])
PR Summary
Allow a user to set the array values to explicit colors with RGB(A) values in the 3rd dimension. We already use
mcolors.to_rgba()to set the facecolors and that will do the RGB(A) handling for us as long as we use 3D arrays. i.e. we can't handle(h*w, 4)flattened arrays with colors.closes #4277
closes #24418
closes #22236 (separate commit to handle pcolorfast in case we want this as a separate PR)
PR Checklist
Documentation and Tests
pytestpasses)Release Notes
.. versionadded::directive in the docstring and documented indoc/users/next_whats_new/.. versionchanged::directive in the docstring and documented indoc/api/next_api_changes/next_whats_new/README.rstornext_api_changes/README.rst