New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
imshow extent keyword (documentation?) #990
Comments
I think the issue is mostly with misleading documentation. While I would like it to behave as documented (assinging extent=(0, 2, 0, 1) is more intuitive to me), it is quite unlikely that we will be able to change that now without the risk of breaking backwards compatibility. I will tag this as a documentation issue and update it accordingly. |
@jomade Can you please comment on my proposed change? |
Nice PR. Closing the issue. |
Just in case anyone finds this via google (like I did), if you want to set the centre of the four corner pixels instead of the
Use it like this:
It's only minimally tested, so use at your own risk ;) |
I'd also be willing to build this into a patch (@pelson, @tacaswell) to add a corner_extents=[] kwarg if you think that would be useful. I find myself doing this thing quite often. |
This seems reasonable to me--but we need a better name! center_extents? pixel_extents? (Actually, I hate the "extents" terminology because I can never remember exactly what it refers to. I would prefer "lrbt". Say, "lrbt_edges" and "lrbt_centers". I suspect this is too much clutter and too much of a departure from tradition to be accepted, though.) |
Closing for lack of activity, and because the original issue has been addressed. |
The imshow documentation as of version 1.1.0 contains the following statement:
Which is kind of correct but misleading in two cases (and why is there stars around x and y? - there is no other x and y in the doc as far as I can see):
Case 1
Extent does not expect a list of indices as described in the text, but only two numbers per dimension (as given in the heading).
I would propose to move the description how data is displayed (with zero based row and column indices) to the top of the documentation
Case 2
The documentation suggests (at least to me) that extent is to specify for the pixel centers and not the borders.
For illustration try:
vs
So
imshow(X, extent=(0, N, 0, M))
will not give you default behaviour.
The default behaviour can be achieved if half a pixel size is added on each side:
imshow(X, extent=(0-0.5, N+0.5, 0-0.5, M+0.5))
I'm not sure if this is intended behaviour or not.
It would be nice to be able to produce and image from the pixel centers given as keyword arguments as
imshow(X, row_axis=range(M), column_axis=range(N))
or something like that.
However, if it is intended behaviour: I would propose the following documentation for the extent keyword:
extent: [ None | scalars (left, right, bottom, top) ]
Data limits for the axes. The limits range from the beginning of the first to the end of the
last pixel. Thus the extent specification for the default behaviour is:
imshow(X, extent=(-0.5, N+0.5, -0.5, M+0.5)).
The text was updated successfully, but these errors were encountered: