What are you trying to do with NonUniformImage that can't be done with imshow or pcolormesh? So far as I can see NonUniformImage is almost completely un-documented.

Thanks for your answer.

imshow assumes a uniform grid of constant spacing in the x and y directions, which I do not have. I have data analogous to the data in the bottom row, where you can see that the width of pixels along the x-axis varies i.e. the grid is non uniform.

I was not aware of pcolormesh, it does, essentially the thing I need, but I need to specify the corners of each pixel, rather than the midpoint of the pixel. So for an image of size Nx,Ny I would need an array of x-values of size Nx+1 and for y of size Ny+1. With NonUniformImage I don't need the extra grid value, I provide the points at which I have data and it assumes some way of finding pixel borders, which is a behaviour I would like.

Anyways, the point is that NonUniformImage could/should, as far as I can see, meaningfully adjust to the axes when they are set to logarithmic scaling, analogous to other image plotting routines. In the example above I show that it ignores the axes.

#9629 does what you want with pcolormesh; right now you can pass N, M vectors, but then the data gets trimmed, which is suboptimal in my opinion.

Skeptical that anyone will get NonUniformImage to work with log axes. Your better bet for now would be to provide pcolormesh with the appropriate x,y vectors that are N+1, M+1 long.

Alright, thanks for the reference and help.

You're welcome to keep this open - maybe someone else thinks NonUniformImage should be kept around and fixed.

Done! Thanks again.

This bug is shared by the PcolorImage used by pcolorfast under some circumstances. It would be nice to fix it for both of these, since they provide a substantial performance boost compared to pcolormesh. Or at a minimum, an exception should be raised when they are used with other than linear scales. Unfortunately, when I looked at this some time ago my impression was that the fix would be non-trivial, and I didn't pursue it.

I think the patch to fix this is along the lines of

diff --git i/lib/matplotlib/image.py w/lib/matplotlib/image.py
index a7642a2cb2..ec585e329c 100644
--- i/lib/matplotlib/image.py
+++ w/lib/matplotlib/image.py
@@ -1066,8 +1066,10 @@ class NonUniformImage(AxesImage):
         l, b, r, t = self.axes.bbox.extents
         width = int(((round(r) + 0.5) - (round(l) - 0.5)) * magnification)
         height = int(((round(t) + 0.5) - (round(b) - 0.5)) * magnification)
-        x_pix = np.linspace(vl.x0, vl.x1, width)
-        y_pix = np.linspace(vl.y0, vl.y1, height)
+        x_pix, _ = self.axes.get_xaxis_transform().inverted().transform(
+            np.column_stack([np.linspace(l, r, width), np.zeros(width)])).T
+        _, y_pix = self.axes.get_yaxis_transform().inverted().transform(
+            np.column_stack([np.zeros(height), np.linspace(b, t, height)])).T
         if self._interpolation == "nearest":
             x_mid = (self._Ax[:-1] + self._Ax[1:]) / 2
             y_mid = (self._Ay[:-1] + self._Ay[1:]) / 2

(i.e. just get the data coordinates corresponding to pixel values). There may just be some off-by-1 or off-by-0.5 things...

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!