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
Better error for SCAMP WCS or support for TPV #3559
I've run into files which use the SCAMP PV?_? convention for distortion coefficients (not standard WCS). This was first raised in #299 and a partial fix was made in #1278. The fix was only partial because it only ignores PV?_? if SIP coefficients are also present, but for files with pure SCAMP distortions, users still get:
InvalidTransformError: ERROR 6 in wcsset() at line 1726 of file cextern/wcslib/C/wcs.c:
PV1_5 : Unrecognized coordinate transformation parameter.
I wonder whether it would be worth at the very least detecting this kind of situation and giving a more explicit error message and possible mitigation strategies. @mdboom indicated in #1278 that he had no time to work on implementing support for the SCAMP distortion terms, but it doesn't mean someone else can't do it - if we could support this deviation from WCS it would make life easier for users, even if it's not 100% standard-compliant.
@astrofrog - yes, it's possible to convert TPV to SIP on-the-fly in an exact way, providing no radial terms are used in TPV (as is the case for SCAMP-generated TPV polynomials).
Sadly, both SIP and TPV are in violation of the FITS WCS standards (since both originate from a time before the standards were completed). I think that @mdboom has put in a workaround in WCSLIB to handle SIP's violation (CTYPEn that are longer than 8 characters). Something similar would need to be done for TPV's use of PV keywords that are reserved in the FITS WCS Paper II.
@astrofrog and @mdboom - there is an additional motivation for astropy.wcs supporting TPV convention, specially for very wide FoV images (where at least 5th order distortion polynomials are required).
SIP images with (A_i_j, B_i_j, AP_i_j, BP_i_j distortion keywords) work fine with astropy.wcs. However, the (ra,dec) coordinates which SExtractor derives from them are not correct, but they are a few arcmin offset in a not systematic fashion (maybe because of the wcslib SIP violation?).
Activity
[-]Better error for SCAMP WCS[/-][+]Better error for SCAMP WCS or support for TPV[/+]astrofrog commentedon Mar 1, 2015
@stargaser - since you've already worked on this, do you think it would be easy to convert the PVi_j formalism to SIP on-the-fly based on your existing work in https://github.com/stargaser/sip_tpv?
astrofrog commentedon Mar 1, 2015
An even better solution would be if support for TPV could be added to WCSLib. @mdboom - do you think that is likely/possible? The standard is described here: http://proceedings.spiedigitallibrary.org/proceeding.aspx?articleid=1363103
stargaser commentedon Mar 1, 2015
@astrofrog - yes, it's possible to convert TPV to SIP on-the-fly in an exact way, providing no radial terms are used in TPV (as is the case for SCAMP-generated TPV polynomials).
Sadly, both SIP and TPV are in violation of the FITS WCS standards (since both originate from a time before the standards were completed). I think that @mdboom has put in a workaround in WCSLIB to handle SIP's violation (CTYPEn that are longer than 8 characters). Something similar would need to be done for TPV's use of PV keywords that are reserved in the FITS WCS Paper II.
ofors commentedon Mar 1, 2015
@astrofrog and @mdboom - there is an additional motivation for astropy.wcs supporting TPV convention, specially for very wide FoV images (where at least 5th order distortion polynomials are required).
SIP images with (A_i_j, B_i_j, AP_i_j, BP_i_j distortion keywords) work fine with astropy.wcs. However, the (ra,dec) coordinates which SExtractor derives from them are not correct, but they are a few arcmin offset in a not systematic fashion (maybe because of the wcslib SIP violation?).
I worked around by converting SIP images to TAN ones with 5th order distortion polynomials (PV_i_j, not PVi_j), using @stargaser 's SIP->TAN exact converter at https://github.com/stargaser/sip_tpv/tree/modularize . In contrary to SIP ones, SExtractor provided correct (ra,dec) coordinates (I matched them to Tycho2) for these converted TAN+PV_i_j images.
I know this is a SExtractor issue, but it is a widely used detection tool, I thought it was worth mentioning this.
ofors commentedon Mar 1, 2015
Oops, let me amend my last message. they're PVi_j, not PV_i_j keywords.
mdboom commentedon Mar 2, 2015
I have a branch for TPV support here (https://github.com/mdboom/astropy/tree/wcs/tpv), which does require changes to wcslib. (No guarantees it is 100% correct yet, but it at least shows the way). I don't want to maintain patches against wcslib, so it would be helpful if someone who needs this functionality could make a case for inclusion in wcslib to Mark Calabretta.
ofors commentedon Mar 3, 2015
Thanks so much @mdboom .
I'll do that: I'll contact Mark Calabretta to request TPV support on wcslib side.
mdboom commentedon Apr 7, 2015
#3669 includes wcslib 5.1 which adds TPV support.
astrofrog commentedon Jun 25, 2015
@mdboom - is this addressed by #3878?
mdboom commentedon Jun 25, 2015
Yes, it is!
ofors commentedon Jun 25, 2015
Thanks a lot @mdboom !
astrofrog commentedon Jun 25, 2015
@mdboom - it might be worth advertising this on astropy-dev since a number of people have in the past asked for support for this if I recall.