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
WCSAxes seem to be dependent on the unit handling of the WCS object #8819
Thank you very much for all the work that you do and thank you in advance for any help. I'm suffering from a very odd issue and I was hoping someone may help. I'm using plot_coord to overplot a field of view on a solar image, but for one of my instruments it complains that I'm using the wrong units, which is not the case. Here is how I'm making the plot:
Thank you Pllim! I'm using SunPy indeed. Though the strange thing is that I'm doing exactly the same thing for 4 other instruments without issue! In every other case plot_coord understands that Arcseconds are arcseconds :(
This still feels like it's a weird bug somewhere, even given the lack of projection (and the resulting madness that induces in WCS) it should still work.
FTR by the time the header made it to WCSAxes in this example it had the CTYPE1 = 'HPLN-'CTYPE2 = HPLT- headers (as SunPy will have added those headers).
The fits file already came with those header cards ('HPLN-' and 'HPLT-'), but if I leave them without the TAN part, it just doesn't work. That's why I overwrote them with
@amunozj yeah, that makes sense, not having the projection affects the way WCS works. However, WCSAxes shouldn't care, which is why I think this is still a bug in WCSAxes because it should be invariant to the unit handling of the WCS object.
WCS changes the units of the header when it interacts with wcslib, which happens when you have a projection, but does not when it doesn't have a projection. This bug therefore is probably that the units of the WCS are not correctly checked and are probably assumed to be deg.
Ah man! this makes so much sense! I was pulling my hair. Why on earth was the thing using degrees, when I was so clearly telling it it was arcseconds. Thank you!
I'm going to close this since things do work fine if the CTYPE is fixed to be valid, and in addition #8664 has been closed so if there was a desire to use a WCS with the original units this is now possible. However feel free to re-open or open a new issue if you feel there is still work to be done here.
Activity
pllim commentedon Jun 11, 2019
Helioprojective? That smells like SunPy. @Cadair ?
amunozj commentedon Jun 11, 2019
Thank you Pllim! I'm using SunPy indeed. Though the strange thing is that I'm doing exactly the same thing for 4 other instruments without issue! In every other case plot_coord understands that Arcseconds are arcseconds :(
amunozj commentedon Jun 11, 2019
Ok Guys. After much hairpulling I think I found the problem. The header of this instrument's fits file was missing two entries:
header['CTYPE1'] = 'HPLN-TAN'
header['CTYPE2'] = 'HPLT-TAN'
Cadair commentedon Jun 11, 2019
This still feels like it's a weird bug somewhere, even given the lack of projection (and the resulting madness that induces in WCS) it should still work.
FTR by the time the header made it to WCSAxes in this example it had the
CTYPE1 = 'HPLN-'CTYPE2 = HPLT-headers (as SunPy will have added those headers).amunozj commentedon Jun 11, 2019
The fits file already came with those header cards (
'HPLN-'and'HPLT-'), but if I leave them without theTANpart, it just doesn't work. That's why I overwrote them withthen it does.
Cadair commentedon Jun 12, 2019
@amunozj yeah, that makes sense, not having the projection affects the way WCS works. However, WCSAxes shouldn't care, which is why I think this is still a bug in WCSAxes because it should be invariant to the unit handling of the WCS object.
pllim commentedon Jun 12, 2019
@Cadair , okay, I'll reopen this.
pllim commentedon Jun 12, 2019
Please update the title with something more descriptive that explains the bug. Thanks!
amunozj commentedon Jun 12, 2019
Any suggestions @pllim, @Cadair ? Would this work?
"WCSAxes seem to be dependent on the unit handling of the WCS object"
[-]plot_coord not using the right units[/-][+]WCSAxes seem to be dependent on the unit handling of the WCS object[/+]pllim commentedon Jun 13, 2019
Well, you understand the bug more than me. 😄 Thanks!
Cadair commentedon Jun 13, 2019
For future readers of this:
WCS changes the units of the header when it interacts with wcslib, which happens when you have a projection, but does not when it doesn't have a projection. This bug therefore is probably that the units of the WCS are not correctly checked and are probably assumed to be deg.
amunozj commentedon Jun 13, 2019
Ah man! this makes so much sense! I was pulling my hair. Why on earth was the thing using degrees, when I was so clearly telling it it was arcseconds. Thank you!
astrofrog commentedon Jun 18, 2019
Related issue: #8664
astrofrog commentedon Jun 18, 2019
So just to check, is there a bug that needs fixing here, or just documentation and #8664?
Cadair commentedon Jun 18, 2019
Well #8664 would fix the bug.
astrofrog commentedon Mar 3, 2026
I'm going to close this since things do work fine if the CTYPE is fixed to be valid, and in addition #8664 has been closed so if there was a desire to use a WCS with the original units this is now possible. However feel free to re-open or open a new issue if you feel there is still work to be done here.