FITS header keywords trigger DSS-specific code, leading to a SingularMatrixError in WCS

[joebro1907]

Description

I’m trying to read the WSC coordinates of a FITS header but I’m having problems with the astropy.wcs.WCS.
This is the error I get:

SingularMatrixError: ERROR 3 in wcsset() at line 2775 of file cextern\wcslib\C\wcs.c:
Linear transformation matrix is singular.
ERROR 3 in linset() at line 718 of file cextern\wcslib\C\lin.c:
PCi_ja matrix is singular.

The FITS header in question is this one: FITS header

There were similar issues reported before, but those were due to having CDELT3 = 0, but I don’t have that entry, only CDELT1 and CDELT2.

After asking in the astropy openastronomy forum, @ayshih correctly pointed out the source of my error was the presence of particular keywords XPIXELSZ and YPIXELSZ, which were triggering DSS-specific code in WCSLIB. Also, it's worth pointing out that ayshih gets a different error when creating a WCS instance:

ValueError: ERROR 5 in wcsset() at line 2808 of file cextern\wcslib\C\wcs.c:
Invalid parameter value.
ERROR 4 in linset() at line 737 of file cextern\wcslib\C\lin.c:
Failed to initialize distortion functions.
ERROR 3 in dssset() at line 2716 of file cextern\wcslib\C\dis.c:
Coefficient scale for DSS on axis 1 is zero..

I have the latest version of astropy, 5.3.4, so I don't get how there are different errors. Besides that, I thought my report in the repository could help reduce the chance of mistakenly triggering the DSS-specific code, as ayshih suggested.

Expected behavior

wcs = WCS(header, naxis = 2) correctly creates a WCS instance.

How to Reproduce

1. Run this python code

from astropy.io import fits
from astropy.wcs import WCS
        
hdu = fits.open(file)
data = hdu[0].data
header = hdu[0].header
wcs = WCS(header, naxis = 2)

2. Solve it by adding this lines:

del (header['XPIXELSZ'], header['YPIXELSZ'])
del (header['CDELTM1'], header['CDELTM2']) # This one is to prevent a warning, not the problem source

Versions

Windows-10-10.0.22631-SP0
Python 3.11.3 (tags/v3.11.3:f3909b8, Apr 4 2023, 23:49:59) [MSC v.1934 64 bit (AMD64)]
astropy 5.3.4
Numpy 1.24.3
pyerfa 2.0.0.3
Scipy 1.10.1
Matplotlib 3.8.0

[github-actions]

Welcome to Astropy 👋 and thank you for your first issue!

A project member will respond to you as soon as possible; in the meantime, please double-check the guidelines for submitting issues and make sure you've provided the requested details.

GitHub issues in the Astropy repository are used to track bug reports and feature requests; If your issue poses a question about how to use Astropy, please instead raise your question in the Astropy Discourse user forum and close this issue.

If you feel that this issue has not been responded to in a timely manner, please send a message directly to the development mailing list. If the issue is urgent or sensitive in nature (e.g., a security vulnerability) please send an e-mail directly to the private e-mail feedback@astropy.org.

[pllim]

I don't get how there are different errors

Without fully reproducible workflows and versions for both sets of errors, it is impossible to know for sure. But you both got errors, so at least that is consistent.

report in the repository could help reduce the chance of mistakenly triggering the DSS-specific code

Thanks, appreciate it! So, is this because DSS is not following the WCS standards and this workaround is needed (in that case, we can close this because there is nothing we can do), or this is a bug in astropy itself that needs fixing?

[ayshih]

I don't get how there are different errors

Without fully reproducible workflows and versions for both sets of errors, it is impossible to know for sure. But you both got errors, so at least that is consistent.

I'll note that the different errors are likely due to the fact that I don't actually have the actual FITS file, and am instead parsing the text version of the header:

>>> from astropy.io.fits import Header
>>> from astropy.wcs import WCS
>>> with open('FITS header.txt') as f:
...     header = Header.fromstring(f.read(), sep='\n')
>>> wcs = WCS(header)

report in the repository could help reduce the chance of mistakenly triggering the DSS-specific code

Thanks, appreciate it! So, is this because DSS is not following the WCS standards and this workaround is needed (in that case, we can close this because there is nothing we can do), or this is a bug in astropy itself that needs fixing?

I haven't dived into WCSLIB myself, but presumably that's where a fix would ideally go. There is a very similar issue (#9883) which already revealed that there is DSS-specific code in WCSLIB that gets triggered if at least one of the DSS-specific keywords is present. So, the question is whether anything can be done so that the DSS-specific code does not get spuriously triggered so easily, and if a fix can't go into WCSLIB, whether something can be done in astropy proper.

[pllim]

Might wanna contact WCSLIB author directly then: https://www.atnf.csiro.au/people/mcalabre/WCS/

[joebro1907]

If it's any help, this the FITS file I used: FITS file a and the corresponding image after the meridian flip FITS file b (denoted by 'a' and 'b' suffixes, respectively).

Although the error is raised with every FTIS file I was working with (42 images), so it's likely either because of how the plate solving is done, or the creation of the FITS files themselves, which was done with PRISM. It's important to mention that these files were given to me, I only performed the alignment and plate solving, not the observation itself, so there's nothing I can do in that regard.