The relax keyword argument controls the handling of non-standard
FITS WCS keywords.
Note that the default value of relax is True for reading (to
accept all non standard keywords), and False for writing (to write
out only standard keywords), in accordance with Postel’s prescription:
“Be liberal in what you accept, and conservative in what you send.”
Header-reading relaxation constants¶
WCS, Wcsprm and
find_all_wcs have a relax argument, which may be
either True, False or an int.
If
True, (default), all non-standard WCS extensions recognized by the parser will be handled.If
False, none of the extensions (even those in the errata) will be handled. Non-conformant keywords will be handled in the same way as non-WCS keywords in the header, i.e. by simply ignoring them.If an
int, is is a bit field to provide fine-grained control over what non-standard WCS keywords to accept. The flag bits are subject to change in future and should be set by using the constants beginning withWCSHDR_in theastropy.wcsmodule.For example, to accept
CD00i00jandPC00i00juse:relax = astropy.wcs.WCSHDR_CD00i00j | astropy.wcs.WCSHDR_PC00i00j
The parser always treats
EPOCHas subordinate toEQUINOXaif both are present, andVSOURCEais always subordinate toZSOURCEa.Likewise,
VELREFis subordinate to the formalism of WCS Paper III.
The flag bits are:
WCSHDR_none: Don’t accept any extensions (not even those in the errata). Treat non-conformant keywords in the same way as non-WCS keywords in the header, i.e. simply ignore them. (This is equivalent to passingFalse)WCSHDR_all: Accept all extensions recognized by the parser. (This is equivalent to the default behavior or passingTrue).WCSHDR_reject: Reject non-standard keyrecords (that are not otherwise explicitly accepted by one of the flags below). A warning will be displayed by default.This flag may be used to signal the presence of non-standard keywords, otherwise they are simply passed over as though they did not exist in the header. It is mainly intended for testing conformance of a FITS header to the WCS standard.
Keyrecords may be non-standard in several ways:
The keyword may be syntactically valid but with keyvalue of incorrect type or invalid syntax, or the keycomment may be malformed.
The keyword may strongly resemble a WCS keyword but not, in fact, be one because it does not conform to the standard. For example,
CRPIX01looks like aCRPIXjakeyword, but in fact the leading zero on the axis number violates the basic FITS standard. Likewise,LONPOLE2is not a validLONPOLEakeyword in the WCS standard, and indeed there is nothing the parser can sensibly do with it.Use of the keyword may be deprecated by the standard. Such will be rejected if not explicitly accepted via one of the flags below.
WCSHDR_CROTAia: AcceptCROTAia,iCROTna,TCROTnaWCSHDR_EPOCHa: AcceptEPOCHa.WCSHDR_VELREFa: AcceptVELREFa.The constructor always recognizes the AIPS-convention keywords,
CROTAn,EPOCH, andVELREFfor the primary representation(a = ' ')but alternates are non-standard.The constructor accepts
EPOCHaandVELREFaonly ifWCSHDR_AUXIMGis also enabled.WCSHDR_CD00i00j: AcceptCD00i00j.WCSHDR_PC00i00j: AcceptPC00i00j.WCSHDR_PROJPn: AcceptPROJPn.These appeared in early drafts of WCS Paper I+II (before they were split) and are equivalent to
CDi_ja,PCi_ja, andPVi_mafor the primary representation(a = ' ').PROJPnis equivalent toPVi_mawithm=n<= 9, and is associated exclusively with the latitude axis.WCSHDR_CD0i_0ja: AcceptCD0i_0ja(wcspih()).WCSHDR_PC0i_0ja: AcceptPC0i_0ja(wcspih()).WCSHDR_PV0i_0ma: AcceptPV0i_0ja(wcspih()).WCSHDR_PS0i_0ma: AcceptPS0i_0ja(wcspih()).Allow the numerical index to have a leading zero in doubly- parameterized keywords, for example,
PC01_01. WCS Paper I (Sects 2.1.2 & 2.1.4) explicitly disallows leading zeroes. The FITS 3.0 standard document (Sect. 4.1.2.1) states that the index in singly-parameterized keywords (e.g.CTYPEia) “shall not have leading zeroes”, and later in Sect. 8.1 that “leading zeroes must not be used” onPVi_maandPSi_ma. However, by an oversight, it is silent onPCi_jaandCDi_ja.Only available if built with wcslib 5.0 or later.
WCSHDR_RADECSYS: AcceptRADECSYS. This appeared in early drafts of WCS Paper I+II and was subsequently replaced byRADESYSa. The constructor acceptsRADECSYSonly ifWCSHDR_AUXIMGis also enabled.WCSHDR_VSOURCE: AcceptVSOURCEaorVSOUna. This appeared in early drafts of WCS Paper III and was subsequently dropped in favor ofZSOURCEaandZSOUna. The constructor acceptsVSOURCEaonly ifWCSHDR_AUXIMGis also enabled.WCSHDR_DOBSn: AllowDOBSn, the column-specific analogue ofDATE-OBS. By an oversight this was never formally defined in the standard.WCSHDR_LONGKEY: Accept long forms of the alternate binary table and pixel list WCS keywords, i.e. with “a” non- blank. Specifically:jCRPXna TCRPXna : jCRPXn jCRPna TCRPXn TCRPna CRPIXja - TPCn_ka : - ijPCna - TPn_ka PCi_ja - TCDn_ka : - ijCDna - TCn_ka CDi_ja iCDLTna TCDLTna : iCDLTn iCDEna TCDLTn TCDEna CDELTia iCUNIna TCUNIna : iCUNIn iCUNna TCUNIn TCUNna CUNITia iCTYPna TCTYPna : iCTYPn iCTYna TCTYPn TCTYna CTYPEia iCRVLna TCRVLna : iCRVLn iCRVna TCRVLn TCRVna CRVALia iPVn_ma TPVn_ma : - iVn_ma - TVn_ma PVi_ma iPSn_ma TPSn_ma : - iSn_ma - TSn_ma PSi_ma
where the primary and standard alternate forms together with the image-header equivalent are shown rightwards of the colon.
The long form of these keywords could be described as quasi- standard.
TPCn_ka,iPVn_ma, andTPVn_maappeared by mistake in the examples in WCS Paper II and subsequently these and alsoTCDn_ka,iPSn_maandTPSn_mawere legitimized by the errata to the WCS papers.Strictly speaking, the other long forms are non-standard and in fact have never appeared in any draft of the WCS papers nor in the errata. However, as natural extensions of the primary form they are unlikely to be written with any other intention. Thus it should be safe to accept them provided, of course, that the resulting keyword does not exceed the 8-character limit.
If
WCSHDR_CNAMnis enabled then also accept:iCNAMna TCNAMna : --- iCNAna --- TCNAna CNAMEia iCRDEna TCRDEna : --- iCRDna --- TCRDna CRDERia iCSYEna TCSYEna : --- iCSYna --- TCSYna CSYERia
Note that
CNAMEia,CRDERia,CSYERia, and their variants are not used byastropy.wcsbut are stored as auxiliary information.WCSHDR_CNAMn: AcceptiCNAMn,iCRDEn,iCSYEn,TCNAMn,TCRDEn, andTCSYEn, i.e. withablank. While non-standard, these are the analogues ofiCTYPn,TCTYPn, etc.WCSHDR_AUXIMG: Allow the image-header form of an auxiliary WCS keyword with representation-wide scope to provide a default value for all images. This default may be overridden by the column-specific form of the keyword.For example, a keyword like
EQUINOXawould apply to all image arrays in a binary table, or all pixel list columns with alternate representationaunless overridden byEQUIna.Specifically the keywords are:
LATPOLEa for LATPna LONPOLEa for LONPna RESTFREQ for RFRQna RESTFRQa for RFRQna RESTWAVa for RWAVna
whose keyvalues are actually used by WCSLIB, and also keywords that provide auxiliary information that is simply stored in the wcsprm struct:
EPOCH - ... (No column-specific form.) EPOCHa - ... Only if WCSHDR_EPOCHa is set. EQUINOXa for EQUIna RADESYSa for RADEna RADECSYS for RADEna ... Only if WCSHDR_RADECSYS is set. SPECSYSa for SPECna SSYSOBSa for SOBSna SSYSSRCa for SSRCna VELOSYSa for VSYSna VELANGLa for VANGna VELREF - ... (No column-specific form.) VELREFa - ... Only if WCSHDR_VELREFa is set. VSOURCEa for VSOUna ... Only if WCSHDR_VSOURCE is set. WCSNAMEa for WCSNna ... Or TWCSna (see below). ZSOURCEa for ZSOUna DATE-AVG for DAVGn DATE-OBS for DOBSn MJD-AVG for MJDAn MJD-OBS for MJDOBn OBSGEO-X for OBSGXn OBSGEO-Y for OBSGYn OBSGEO-Z for OBSGZn
where the image-header keywords on the left provide default values for the column specific keywords on the right.
Keywords in the last group, such as
MJD-OBS, apply to all alternate representations, soMJD-OBSwould provide a default value for all images in the header.This auxiliary inheritance mechanism applies to binary table image arrays and pixel lists alike. Most of these keywords have no default value, the exceptions being
LONPOLEaandLATPOLEa, and alsoRADESYSaandEQUINOXawhich provide defaults for each other. Thus the only potential difficulty in usingWCSHDR_AUXIMGis that of erroneously inheriting one of these four keywords.Unlike
WCSHDR_ALLIMG, the existence of one (or all) of these auxiliary WCS image header keywords will not by itself cause aWcsprmobject to be created for alternate representationa. This is because they do not provide sufficient information to create a non-trivial coordinate representation when used in conjunction with the default values of those keywords, such asCTYPEia, that are parameterized by axis number.WCSHDR_ALLIMG: Allow the image-header form of all image header WCS keywords to provide a default value for all image arrays in a binary table (n.b. not pixel list). This default may be overridden by the column-specific form of the keyword.For example, a keyword like
CRPIXjawould apply to all image arrays in a binary table with alternate representationaunless overridden byjCRPna.Specifically the keywords are those listed above for
WCSHDR_AUXIMGplus:WCSAXESa for WCAXna
which defines the coordinate dimensionality, and the following keywords which are parameterized by axis number:
CRPIXja for jCRPna PCi_ja for ijPCna CDi_ja for ijCDna CDELTia for iCDEna CROTAi for iCROTn CROTAia - ... Only if WCSHDR_CROTAia is set. CUNITia for iCUNna CTYPEia for iCTYna CRVALia for iCRVna PVi_ma for iVn_ma PSi_ma for iSn_ma CNAMEia for iCNAna CRDERia for iCRDna CSYERia for iCSYna
where the image-header keywords on the left provide default values for the column specific keywords on the right.
This full inheritance mechanism only applies to binary table image arrays, not pixel lists, because in the latter case there is no well-defined association between coordinate axis number and column number.
Note that
CNAMEia,CRDERia,CSYERia, and their variants are not used by pywcs but are stored in theWcsprmobject as auxiliary information.Note especially that at least one
Wcsprmobject will be returned for eachafound in one of the image header keywords listed above:If the image header keywords for
aare not inherited by a binary table, then the struct will not be associated with any particular table column number and it is up to the user to provide an association.If the image header keywords for
aare inherited by a binary table image array, then those keywords are considered to be “exhausted” and do not result in a separateWcsprmobject.
Header-writing relaxation constants¶
to_header and to_header_string
has a relax argument which may be either True, False or an
int.
If
True, write all recognized extensions.If
False(default), write all extensions that are considered to be safe and recommended, equivalent toWCSHDO_safe(described below).If an
int, is is a bit field to provide fine-grained control over what non-standard WCS keywords to accept. The flag bits are subject to change in future and should be set by using the constants beginning withWCSHDO_in theastropy.wcsmodule.
The flag bits are:
WCSHDO_none: Don’t use any extensions.WCSHDO_all: Write all recognized extensions, equivalent to setting each flag bit.WCSHDO_safe: Write all extensions that are considered to be safe and recommended.WCSHDO_DOBSn: WriteDOBSn, the column-specific analogue ofDATE-OBSfor use in binary tables and pixel lists. WCS Paper III introducedDATE-AVGandDAVGnbut by an oversightDOBSnwas never formally defined by the standard. The alternative to usingDOBSnis to writeDATE-OBSwhich applies to the whole table. This usage is considered to be safe and is recommended.WCSHDO_TPCn_ka: WCS Paper I definedTPn_kaandTCn_kafor pixel listsbut WCS Paper II uses
TPCn_kain one example and subsequently the errata for the WCS papers legitimized the use ofTPCn_kaandTCDn_kafor pixel listsprovided that the keyword does not exceed eight characters. This usage is considered to be safe and is recommended because of the non-mnemonic terseness of the shorter forms.
WCSHDO_PVn_ma: WCS Paper I definediVn_maandiSn_mafor bintables andTVn_maandTSn_mafor pixel listsbut WCS Paper II uses
iPVn_maandTPVn_main the examples and subsequently the errata for the WCS papers legitimized the use ofiPVn_maandiPSn_mafor bintables andTPVn_maandTPSn_mafor pixel listsprovided that the keyword does not exceed eight characters. This usage is considered to be safe and is recommended because of the non-mnemonic terseness of the shorter forms.
WCSHDO_CRPXna: For historical reasons WCS Paper I definedjCRPXn,iCDLTn,iCUNIn,iCTYPn, andiCRVLnfor bintables andTCRPXn,TCDLTn,TCUNIn,TCTYPn, andTCRVLnfor pixel listsfor use without an alternate version specifier. However, because of the eight-character keyword constraint, in order to accommodate column numbers greater than 99 WCS Paper I also defined
jCRPna,iCDEna,iCUNna,iCTYnaandiCRVnafor bintables andTCRPna,TCDEna,TCUNna,TCTYnaandTCRVnafor pixel listsfor use with an alternate version specifier (the
a). Like thePC,CD,PV, andPSkeywords there is a tendency to confuse these two forms for column numbers up to 99. It is very unlikely that any parser would reject keywords in the first set with a non-blank alternate version specifier so this usage is considered to be safe and is recommended.
WCSHDO_CNAMna: WCS Papers I and III definediCNAna,iCRDna, andiCSYnafor bintables andTCNAna,TCRDna, andTCSYnafor pixel listsBy analogy with the above, the long forms would be
iCNAMna,iCRDEna, andiCSYEnafor bintables andTCNAMna,TCRDEna, andTCSYEnafor pixel listsNote that these keywords provide auxiliary information only, none of them are needed to compute world coordinates. This usage is potentially unsafe and is not recommended at this time.
WCSHDO_WCSNna: WriteWCSNnainstead ofTWCSnafor pixel lists. While the constructor treatsWCSNnaandTWCSnaas equivalent, other parsers may not. Consequently, this usage is potentially unsafe and is not recommended at this time.WCSHDO_SIP: Write out Simple Imaging Polynomial (SIP) keywords.WCSHDO_P12,WCSHDO_P13,WCSHDO_P14,WCSHDO_P15,WCSHDO_P16,WCSHDO_P17,WCSHDO_EFMTThese constants control the precision of the WCS keywords returned by
to_header.WCSHDO_P12: Use “%20.12G” format for all floating-point keyvalues (12 significant digits)WCSHDO_P13: Use “%21.13G” format for all floating-point keyvalues (13 significant digits)WCSHDO_P14: Use “%22.14G” format for all floating-point keyvalues (14 significant digits)WCSHDO_P15: Use “%23.15G” format for all floating-point keyvalues (15 significant digits)WCSHDO_P16: Use “%24.16G” format for all floating-point keyvalues (16 significant digits)WCSHDO_P17: Use “%25.17G” format for all floating-point keyvalues (17 significant digits)WCSHDO_EFMT: Use “%E” format instead of the default “%G” format above