Repository navigation
New astropy WCS class incompatible with Anaconda #113
Description
The changes done in #108 give the following errors when I use astropy 1.0.3 that is part of Anaconda:
[WARNI] Bad coordinate conversion: 'AstropyWCS2' object has no attribute 'coordsys'
[ERROR] Traceback:
File ".../ginga-2.4.20150603003439-py2.7.egg/ginga/AstroImage.py", line 621, in info_xy
elif self.wcs.coordsys == 'raw':
Activity
pllim commentedon Jun 8, 2015
Other errors from the same PR as above:
and
ejeschke commentedon Jun 8, 2015
@Cadair, would you mind taking a look at this? I think this is in your code, and I haven't yet looked through it to see what exactly is going on.
Cadair commentedon Jun 8, 2015
I will take a look at this, I don't have much time at the moment.
@pllim Is this particularly urgent? You can override the WCS system right?
ejeschke commentedon Jun 8, 2015
@plim, for the moment you can simply set
in your
$HOME/.ginga/general.cfgpllim commentedon Jun 8, 2015
@ejeschke , changing the setting to
'astropy'works for me. Thanks! @Cadair , since there is a work-around, this issue is not urgent.Cadair commentedon Jun 8, 2015
@pllim I don't seem to be able to replicate this. I managed to open an image in native fk5 and after setting the display coordinate system to something sensible it seems to work fine, I get mouse over coords and the compass.
I am using astropy 1.0.3 from conda and installing ginga from master. Can you tell me more about your setup?
pllim commentedon Jun 9, 2015
Using
ginga.util.wcsmod.AstropyWCS, I get the following when I access itswcs.wcsattribute:I cannot load the header at all with
AstropyWCS2.Admittedly, the WCS information is bogus (someone else made it up, not me!). With
AstropyWCS, the compass looks all weird on Ginga, i.e., N and E are not perpendicular. For my purpose, I don't care. But I don't understand whyAstropyWCSworks but notAstropyWCS2.pllim commentedon Jun 9, 2015
I cannot share the image nor its full header, but if you need certain header keywords, please let me know and I'll post the values here. Thanks!
Cadair commentedon Jun 9, 2015
@pllim hmmm, is it in a coordinate system supported by astropy coordinates?
pllim commentedon Jun 9, 2015
How do I find out? Like I said,
AstropyWCSworks.Cadair commentedon Jun 9, 2015
what do you get when you run the WCS object through this: http://docs.astropy.org/en/stable/api/astropy.wcs.utils.wcs_to_celestial_frame.html#astropy.wcs.utils.wcs_to_celestial_frame
pllim commentedon Jun 9, 2015
Cadair commentedon Jun 9, 2015
Interesting. What coordinate system is the WCS describing?
I a test file with an unknown WCS. Could you make a derivative of your file that still reproduces that error?
pllim commentedon Jun 9, 2015
After carefully combing through the header, I realized that it might not have any WCS keywords at all. I can reproduce the same thing by replacing the input header with empty FITS header:
😱
Cadair commentedon Jun 9, 2015
haha nice! Thanks.
Ok I will try and give this a go, but as I say might not be for a while, hard to know at the moment.
pllim commentedon Jun 9, 2015
No problem, there is no rush on my end. Whatever the solution is, would be nice for
AstropyWCSandAstropyWCS2to at least behave consistently. Thanks for looking into this!ejeschke commentedon Dec 9, 2015
I believe this is fixed by PR #206. Feel free to reopen if see otherwise, @pllim.
pllim commentedon Dec 9, 2015
Nope, still getting the same errors. I am using
astropy 1.1rc2. You can probably recreate the traceback yourself by using an image without any WCS information.ejeschke commentedon Dec 9, 2015
Hmm, I think the problems may go a little further. When I use a file that has WCS keywords, but with a
CUNIT{1,2} of type 'pixel', with the originalastropywcs wrapper it succeeds to create the WCS and resolves to reporting pixels. I get this with the new version of theastropy2wrapper:@eteq just pinging you as you and @Cadair are the authors/editors of this wrapper.
eteq commentedon Dec 9, 2015
@ejeschke - hmm, I think this was just a mistake in #206, which I can try to fix.
The basic issue here is that in the new
AstropyWCS2implementation,coordsys(which is renamedcoordframeto be more clear- see this docstring) is usually an astropy coordinate frame object, but occasionally is a string. This may be entirely do to my confusion, though: sometimes the ginga WCS machinery wants it to be "raw" or "pixel", and it's not clear to me what these are supposed to mean (or are they the same?). It's also not clear to me which methods are actually used outside of the class itself, so I'm not sure where the best place is to implement overrides that catch the "string" cases. Can you clarify this for me? If so I think I can craft a PR to fix this.ejeschke commentedon Dec 9, 2015
I think the problem is that that
coordsysattribute, which is exposed (and used) outside the wrapper, needs to be a string. The string is examined to decide how to interpret the output of the wcs. For example, if the type is 'pixel', then the result of running the data coordinate through the wrapper is a pixel coordinate, and it shouldn't be further transformed (e.g. ICRS->galactic).So I think in
astropy2this needs to revert to a string and simply use a different (internal) variable to hold any coordinates/frames used in the transformation.ejeschke commentedon Dec 9, 2015
To be more specific,
coordsysshould be determined by thewcsmod.get_coord_system_namemodule level function, unless some of the types cannot be supported by astropy. But I believe all of the ones returned by that function can be supported by astropy2. 'raw' means no sensible WCS keywords could be detected, and so the wrapper functions won't even be called, and 'pixel' will only incur a single wcs transform (data->pixel) and so it won't have to map one frame type to another frame type.eteq commentedon Dec 16, 2015
Ohh, gotcha - I didn't realize
coordsyswas used outside of the wcs class itself. So indeed that's probably the issue. Will try to get in a fix for that.