Incompatible results from WCS.pixel_to_world between astropy 3.x and 4.x (distortion in WCSLIB 6.3 + Cutout2D)

EDIT: The cause identified in https://github.com/astropy/astropy/issues/11216#issuecomment-755754911

Description

The use of WCS.pixel_to_world gives different results when using astropy 3.x or 4.x (same environment).

Expected behavior

The two astropy versions should give the same results, or expected incompatibilities should be quoted explicitly in the documentation.

Actual behavior

The two astropy versions give different results, and I could not find a documentation on it.

Steps to Reproduce

The common.fits can be found here (37 KB).

from astropy.io import fits
from astropy.wcs import WCS

fn = "common.fits"

header = fits.open(fn)[0].header
w = WCS(header)

print(w.pixel_to_world([[0, 0]], 0))
# astropy 3.2.2: 
# <SkyCoord (FK5: equinox=2000.0): (ra, dec) in deg
#   [[(250.51824533, -75.47419369), (250.51824533, -75.47419369)]]>
# astropy 4.0.1.post1:
# <SkyCoord (FK5: equinox=2000.0): (ra, dec) in deg
#   [[(251.99786293, -75.83653121), (251.99786293, -75.83653121)]]>

I am not sure what’s happening here. I have the impression the information from the header is used differently in the two astropy versions, but I cannot find what has changed explicitly in the documentation.

System Details

Darwin-20.2.0-x86_64-i386-64bit
Python 3.7.1 (default, Oct 23 2018, 14:07:42)
[Clang 4.0.1 (tags/RELEASE_401/final)]
Numpy 1.16.2
astropy 3.2.2
Scipy 1.4.1
Matplotlib 3.0.1

Darwin-20.2.0-x86_64-i386-64bit
Python 3.7.1 (default, Oct 23 2018, 14:07:42)
[Clang 4.0.1 (tags/RELEASE_401/final)]
Numpy 1.16.2
astropy 4.0.1.post1
Scipy 1.4.1
Matplotlib 3.0.1

Checked also using the official docker images (https://hub.docker.com/u/continuumio/): 2019.10 (astropy 3.2.2), 2020.02 (astropy 4.0), 2020.07 (astropy 4.0.1.post1), 2020.11 (astropy 4.0.2).

[dhomeier]

I note that the distortion-free parts of the WCS (using the header without the CQDIS/DQ cards) return identical results: 3.2.2

>>> w = wcs.WCS(fits.Header.fromstring(hdr[:1802], sep='\n'))
>>> wd = wcs.WCS(fits.Header.fromstring(hdr, sep='\n'))
>>> w.pixel_to_world(0, 0)
<SkyCoord (FK5: equinox=2000.0): (ra, dec) in deg
    (250.51820607, -75.47417884)>
>>> wd.pixel_to_world(0, 0).separation(w.pixel_to_world(0, 0))
<Angle 1.78130314e-05 deg>

4.2

>>> w = wcs.WCS(fits.Header.fromstring(hdr[:1802], sep='\n'))
>>> wd = wcs.WCS(fits.Header.fromstring(hdr, sep='\n'))
>>> w.pixel_to_world(0, 0)
<SkyCoord (FK5: equinox=2000.0): (ra, dec) in deg
    (250.51820607, -75.47417884)>
>>> wd.pixel_to_world(0, 0).separation(w.pixel_to_world(0, 0))
<Angle 0.51542227 deg>
>>> w.pixel_to_world(736.32251317135, 806.0426298396).separation(w.pixel_to_world(0, 0))
<Angle 0.51548823 deg>
>>> wd.pixel_to_world(736.32251317135, 806.0426298396).separation(wd.pixel_to_world(0, 0))
<Angle 1.0309105 deg>

IOW in the 4.x version the distortion seems to offset the point by almost exactly the full distance to CRPIX1, CRPIX2 again (instead of ~64 mas, blowing up the field by a factor of 2)! Unless this is an almost pathologically distorted WCS (does not look like it, with diagonal coefficients close to 1.0 AFAICS), this looks like a serious bug.

[JulienPeloton]

Hi @pllim – thanks for the follow-up. I did not get more into the details since last year, and did not encounter this problem again in my work.