Skip to content

Document pixel coordinate convention for Astropy #2607

Closed

Description

@cdeil

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.

@eteq @astrofrog @keflavich @embray Do you think this is a good idea? If yes, where should I put this page?

Activity

  1. keflavich commented on Jun 9, 2014

    @keflavich
    Contributor

    👍, but I can't say where to put it. I'm particularly enthusiastic to see the "best practices for meshgrid + wcs" laid out.

  2. astrofrog commented on Jun 9, 2014

    @astrofrog
    Member

    👍 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.

  3. larrybradley commented on Jun 9, 2014

    @larrybradley
    Member

    👍. And I like @astrofrog's suggestion of Conventions in Astropy.

  4. eteq commented on Jun 12, 2014

    @eteq
    Member

    👍 to @astrofrog's suggestion from me, too. Anyone want to volunteer to do the PR?

  5. cdeil commented on Jun 12, 2014

    @cdeil
    MemberAuthor

    I've started to write this up ... will add commits here in the next days.

  6. added this to the v1.0.0 milestone on Jul 21, 2014
  7. eteq commented on Aug 10, 2014

    @eteq
    Member

    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?

    (This may require a larger discussion, but lets start with @cdeil @astrofrog @larrybradley )

  8. kbarbary commented on Aug 10, 2014

    @kbarbary
    Member

    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...

  9. astrofrog commented on Aug 10, 2014

    @astrofrog
    Member

    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...

  10. larrybradley commented on Aug 12, 2014

    @larrybradley
    Member

    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).

  11. pllim commented on Aug 12, 2014

    @pllim
    Member

    👍 to [y, x] because that is what I expect from Python.

  12. perrygreenfield commented on Aug 12, 2014

    @perrygreenfield
    Member

    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.

  13. astrofrog commented on Jan 14, 2015

    @astrofrog
    Member

    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!)

  14. removed this from the v1.0.0 milestone on Jan 14, 2015
  15. cdeil commented on Dec 14, 2018

    @cdeil
    MemberAuthor
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions