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
Document pixel coordinate convention for Astropy #2607
In photutils @kbarbary added a description of the pixel coordinate convention here. I think this should be moved to Astropy core now, as it is (I think) uncontroversial but needs to be documented and followed consistently in Astropy core and affiliated packages.
It's not quite clear where to put it though, because it relates to a bit to astropy.nddata, astropy.modeling and astropy.wcs. I think we should make a new array_coordinate_convention.rst page and also add some code examples of how to use np.meshgrid, np.indices, wcs etc correctly with astropy.modeling, astropy.nddata and astropy.wcs and mention that one has to use origin='lower' with plt.imshow to get an "astronomically correctly oriented" image.
👍 from me - also not sure where it should fit. This page contains some conventions for importing, so maybe something in a similar place would be good. Alternatively, there could be a new sub-section after Astropy at a glance called Conventions in Astropy and some of the import guidelines could be moved there.
While revisiting this in the astropy.imageutils#18 discussion, I looked over @kbarbary's conventions again, and noticed something that I hadn't seen before: the pixel convention is [y, x] instead of [x, y]
I realize this is because that's what fits outputs, and what pyplot.imshow expects. But do we really want to say this is the convention? I think it's backwards from what most astronomers/physicists are likely to expect, right?
I think this has to be the convention because the alternative is much more confusing: If we called the slow axis x and the fast axis y, the axis names would be swapped with respect to FITS viewing tools like ds9.
My personal algorithm for remembering axis order is that the fast (memory-contiguous) axis is always called x. Given that information, it makes sense to index like [y, x] in Python. Don't know if that helps...
I think that [y,x] is actually not just related to FITS, but as you said also matplotlib's imshow. Enough tutorials in various places make the point that the axes are swapped, so if we now introduce a context where users can use [x,y], things will get confusing...
I agree that changing everything to use [x, y] indexing would be more confusing. I think most astronomers who use python/numpy/scipy/matplotlib are used to row-major [y, x] order (how the data are stored in memory).
This is just one of those things one needs to train newcomers on to get them to think [y,x]. Otherwise it will haunt them forever given confusion regarding what convention is being used. It is almost always better to accept the language convention than to try to fight it.
Activity
keflavich commentedon Jun 9, 2014
👍, but I can't say where to put it. I'm particularly enthusiastic to see the "best practices for
meshgrid+wcs" laid out.astrofrog commentedon Jun 9, 2014
👍 from me - also not sure where it should fit. This page contains some conventions for importing, so maybe something in a similar place would be good. Alternatively, there could be a new sub-section after Astropy at a glance called Conventions in Astropy and some of the import guidelines could be moved there.
larrybradley commentedon Jun 9, 2014
👍. And I like @astrofrog's suggestion of Conventions in Astropy.
eteq commentedon Jun 12, 2014
👍 to @astrofrog's suggestion from me, too. Anyone want to volunteer to do the PR?
cdeil commentedon Jun 12, 2014
I've started to write this up ... will add commits here in the next days.
eteq commentedon Aug 10, 2014
While revisiting this in the astropy.imageutils#18 discussion, I looked over @kbarbary's conventions again, and noticed something that I hadn't seen before: the pixel convention is
[y, x]instead of[x, y]I realize this is because that's what fits outputs, and what
pyplot.imshowexpects. But do we really want to say this is the convention? I think it's backwards from what most astronomers/physicists are likely to expect, right?(This may require a larger discussion, but lets start with @cdeil @astrofrog @larrybradley )
kbarbary commentedon Aug 10, 2014
I think this has to be the convention because the alternative is much more confusing: If we called the slow axis
xand the fast axisy, the axis names would be swapped with respect to FITS viewing tools like ds9.My personal algorithm for remembering axis order is that the fast (memory-contiguous) axis is always called
x. Given that information, it makes sense to index like[y, x]in Python. Don't know if that helps...astrofrog commentedon Aug 10, 2014
I think that
[y,x]is actually not just related to FITS, but as you said also matplotlib'simshow. Enough tutorials in various places make the point that the axes are swapped, so if we now introduce a context where users can use[x,y], things will get confusing...larrybradley commentedon Aug 12, 2014
I agree that changing everything to use
[x, y]indexing would be more confusing. I think most astronomers who use python/numpy/scipy/matplotlib are used to row-major[y, x]order (how the data are stored in memory).pllim commentedon Aug 12, 2014
👍 to
[y, x]because that is what I expect from Python.perrygreenfield commentedon Aug 12, 2014
This is just one of those things one needs to train newcomers on to get them to think [y,x]. Otherwise it will haunt them forever given confusion regarding what convention is being used. It is almost always better to accept the language convention than to try to fight it.
astrofrog commentedon Jan 14, 2015
This is not critical to 1.0, so removing milestone (but if someone wants to work on this in the next few days, we can include it!)
cdeil commentedon Dec 14, 2018
This exists now here: http://docs.astropy.org/en/stable/wcs/wcsapi.html#pixel-conventions-and-definitions
Closing this old issue from 2014.