Skip to content
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

RA not returned correctly for cubes with orthographic/synthesis projection #864

Open
TimothyADavis opened this issue Feb 24, 2023 · 8 comments

Comments

@TimothyADavis
Copy link

Dear spectral-cube team,

I have come across a fun issue where the RA coordinate grids returned by e.g. cube.world[:] are not correct when the FITS file has an orthographic/synthesis projection (e.g. RA---SIN and DEC--SIN).

For instance in my cube the RA coordinate predicted by cube.world for some given pixel is -164.004 deg, while cube.wcs.pixel_to_world returns the correct 195.819 deg.

Many thanks,
Tim Davis

@TimothyADavis TimothyADavis changed the title RA/Dec not returned correctly for cubes with orthographic/synthesis projection RA not returned correctly for cubes with orthographic/synthesis projection Feb 24, 2023
@keflavich
Copy link
Contributor

Could you provide the header for said file?

@TimothyADavis
Copy link
Author

Hi Adam - of course, find that attached. CARTA and astropy.wcs seem to cope with it fine.

component1.fits-Header.txt

@low-sky
Copy link
Contributor

low-sky commented Feb 24, 2023

I think there's just a difference in convention here since the cube.world is returning results from astropy.wcs.all_pixel2world whereas you might be seeing the results from astropy.wcs.pixel_to_world. Since the header you supplied has a negative CRVAL1 the former is returning a negative value and the latter adds the 360° to put it inside the standard range. I am unable to replicate a small offset beyond this 360° shift that could be attributable to mishandling a projection since it's all astropy under the hood.

However, it might be good to move the SpectralCube.world attributes to using astropy.wcs.pixel_to_world since it comes with some units and astropy is catching up on spectral axis handling.

@keflavich
Copy link
Contributor

We're using the lower-level routines rather than the Coordinates routines in part for performance reasons; I think there is overhead in creating a huge array of coordinates. However, we could check what the performance cost is and see if switching to pixel_to_world is acceptable.

@TimothyADavis Could you verify that there is a genuine offset, not just a wrap? (-164 = 196, but your coordinates gave a difference of ~0.17 deg)

@TimothyADavis
Copy link
Author

After some investigation, it seems that it is just the wrap (I may have extracted the wrong pixel to compare before). Negative RAs just go on to break code further up my pipeline, which is why I started seeing the issue. I can always add the wrap myself- just thought I would bring it up as it seemed strange to get different results from these two routines. Cheers!

@keflavich
Copy link
Contributor

I agree it is a bit weird. astropy coordinates have a wrap_at option to specify the convention (you want -180 < lon < 180 near lon=0, 0 < lon < 360 at lon ~ 180), but I'm not sure that that option exists for the lower-level pix2world routines.

@e-koch
Copy link
Contributor

e-koch commented Mar 1, 2023

Thanks for raising this, @TimothyADavis.

I noticed in the header that the CRVALs are negative:

CRVAL1 = -1.641802500000E+02
CRVAL2 = -1.742302777778E+01

It'd be ideal if spectral-cube via astropy coords can handle the wrapping, but I'm wondering if anyone knows if the negative CRVALs are accepted under the FITS standard? This might be a bug upstream in WSClean and how it writes headers.

@preshanth
Copy link
Collaborator

@e-koch the fits standard only says CRVAL for a given coordinate system needs to be floating point no other specifications beyond that. Negative values are permissible but the question is does it make sense as a reference for the coordinate system?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants