You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[Bug]: pcolormesh/pcolor doesn't show the image of an array of (M*1) OR (1*M) when providing X and Y explicitly #25699
pcolormesh/pcolor doesn't display the image of an array of size M*1 or 1*M when providing the parameters X and Y explicitly. If only the paramter C is provided, the two functions work well.
Code for reproduction
importmatplotlib.pyplotaspltimportnumpyasnpx, y=np.meshgrid([1,2], [1])
z=x+yplt.pcolor(x, y, z) # or plt.pcolormesh(x, y, z), both of which give an empty figure.plt.pcolor(z) # or plt.pcolormesh(z), both of which work well.
Actual outcome
plt.pcolor(x, y, z) gives an empty figure, while plt.pcolor(z) works as expected.
Expected outcome
Both of plt.pcolor(x, y, z) and plt.pcolor(z) should show the chart.
Additional information
No response
Operating system
Windows
Matplotlib Version
3.7.1
Matplotlib Backend
module://matplotlib_inline.backend_inline OR QtAgg
If you only specify z we fake cell edges for you. If you specify x and y, but only at the centres, we create cell edges for you by using np.diff(x) to determine the cell sizes. In this case you don't have enough y data for us to determine how high the single cell should be.
If you only specify one cell centre, what value should we give to the cell width? In this case you might say dy = 1, but what if y = 1e-6 or y=1e6?
So we have a a few choices. 1) stay as is, which is maybe a bit mystifying. 2) add a warning for the degenerate case, 3) just use some multiple of the absolute value of y?
To work around the ambiguity, you can specify x and y on the edges:
I think we should stay as is or perhaps even throw an exception.
If we really want to guess a dy I think it should be dy=1 rather than some fraction of y, as the latter would still not work if y=0, and would likely not make any sense if y has units (e.g. dates or categoricals).
"Stay as-is" is not an option. The plot command has no visual effect. Without functional change, we'd need a warning or error ("errors should never pass siltently").
The question between warning, error and use a default dy is: What user intention do we anticipate:
In the case of no x/y the user only wants to visualize the structure and does not care about positions or limits. -> Rendering here is ok.
I personally have use cases where the data values represent (point-)measurement on a non-uniform grid. It's visually nice to color the surrounding "pixels" (equivalent to a nearest-neighbor interpolation). There can also be cases with just one row of data. Intuitively I'd want visualize these as well with squarish pixels. So dy=mean(dx) (or median?).
Overall there are two valid approaches:
Puristic: Error out (In the face of ambiguity refuse the temptation to guess)
Anticipating: Plot with squarish pixels and warn.
I'd go for 2) because there is little harm in that. If we are lucky, the output is useful for the user. If not, they get an unwanted plot and a warning, which is not really worse than an exception. But I can also live with 1).
IMHO, if the array is a one-row one, it doesn't matter whether y is 1 or 1e6, because the height of a single cell is just the height of an Axes's height. In the data coordinates, y may be different, but in the axes fraction coordinates, y is same for any one-row array. In this case, the y axis may not be in the same scale as the x axis, so giving users a warning is preferred.
I agree with @timhoffm. "Stary as-is" makes some users like me confused.
This issue has been marked "inactive" because it has been 365 days since the last comment. If this issue is still present in recent Matplotlib releases, or the feature request is still wanted, please leave a comment and this label will be removed. If there are no updates in another 30 days, this issue will be automatically closed, but you are free to re-open or create a new issue if needed. We value issue reports, and this procedure is meant to help us resurface and prioritize issues that have not been addressed yet, not make them disappear. Thanks for your help!
I think warning and guessing a dX instead of erroring is a good approach. I found a discussion related to this, and I do agree with #16258 (comment) .
dX = np.abs(X) / 2 on either side (and -+0.5 for zero) seems like the better default. It may be akward for dates and categoricals but the warning should alert the user who can provide explicit cell corners instead.
Activity
jklymak commentedon Apr 16, 2023
If you only specify
zwe fake cell edges for you. If you specify x and y, but only at the centres, we create cell edges for you by usingnp.diff(x)to determine the cell sizes. In this case you don't have enough y data for us to determine how high the single cell should be.If you only specify one cell centre, what value should we give to the cell width? In this case you might say dy = 1, but what if y = 1e-6 or y=1e6?
So we have a a few choices. 1) stay as is, which is maybe a bit mystifying. 2) add a warning for the degenerate case, 3) just use some multiple of the absolute value of y?
To work around the ambiguity, you can specify x and y on the edges:
anntzer commentedon Apr 18, 2023
I think we should stay as is or perhaps even throw an exception.
If we really want to guess a dy I think it should be dy=1 rather than some fraction of y, as the latter would still not work if y=0, and would likely not make any sense if y has units (e.g. dates or categoricals).
timhoffm commentedon Apr 19, 2023
"Stay as-is" is not an option. The plot command has no visual effect. Without functional change, we'd need a warning or error ("errors should never pass siltently").
The question between warning, error and use a default dy is: What user intention do we anticipate:
In the case of no x/y the user only wants to visualize the structure and does not care about positions or limits. -> Rendering here is ok.
I personally have use cases where the data values represent (point-)measurement on a non-uniform grid. It's visually nice to color the surrounding "pixels" (equivalent to a nearest-neighbor interpolation). There can also be cases with just one row of data. Intuitively I'd want visualize these as well with squarish pixels. So
dy=mean(dx)(or median?).Overall there are two valid approaches:
I'd go for 2) because there is little harm in that. If we are lucky, the output is useful for the user. If not, they get an unwanted plot and a warning, which is not really worse than an exception. But I can also live with 1).
jklymak commentedon Apr 19, 2023
I think 2 is reasonable.
For a default, I'd propose dy = np.abs(y) / 2 on either side of y, or +/- 0.5 if y=0.
I don't think dy = mean(dx) is an option: x and y can be in different units, let alone different orders of magnitude.
chenyulue commentedon Apr 21, 2023
IMHO, if the array is a one-row one, it doesn't matter whether y is 1 or 1e6, because the height of a single cell is just the height of an
Axes's height. In the data coordinates, y may be different, but in the axes fraction coordinates, y is same for any one-row array. In this case, the y axis may not be in the same scale as the x axis, so giving users a warning is preferred.I agree with @timhoffm. "Stary as-is" makes some users like me confused.
github-actions commentedon Jun 8, 2026
This issue has been marked "inactive" because it has been 365 days since the last comment. If this issue is still present in recent Matplotlib releases, or the feature request is still wanted, please leave a comment and this label will be removed. If there are no updates in another 30 days, this issue will be automatically closed, but you are free to re-open or create a new issue if needed. We value issue reports, and this procedure is meant to help us resurface and prioritize issues that have not been addressed yet, not make them disappear. Thanks for your help!
rcomer commentedon Jun 9, 2026
I also have a use-case for this. I would have been happy with an exception that told me I can make it work by specifying cell edges.
lucaznch commentedon Sep 27, 2026
I think warning and guessing a dX instead of erroring is a good approach. I found a discussion related to this, and I do agree with #16258 (comment) .
dX = np.abs(X) / 2 on either side (and -+0.5 for zero) seems like the better default. It may be akward for dates and categoricals but the warning should alert the user who can provide explicit cell corners instead.