Count CRPIX from zero, as named_arrays does

[roytsmart]

SpectrographObservation.from_fits put the CRPIX keywords into
named_arrays.AbstractWcsVector exactly as astropy.wcs reported them,
and astropy reports them as the header writes them, which FITS counts
from one.

The formula they are used in is the one in the WCS paper and is written
out correctly:

p = na.CartesianNdVectorArray(na.indices(shape_wcs)) - 0.5
q = m @ (p - r)
x = s * q + crval

but p comes from named_arrays.indices and so counts from zero, while
r arrived counting from one. Subtracting one from the other mixes the
two conventions and moves everything by a pixel. The - 0.5 already
there is a separate thing: it turns cell centers into the cell edges this
grid is built on, and says nothing about where counting starts.

Measured on iris_l2_20210923_...:

axis	one pixel
wavelength, Si IV 1394	0.0127 Å = 2.76 km/s
solar x, across the raster	0.349″
solar y, along the slit	0.166″

cdelt is positive, so wavelengths came out one pixel low and velocities
carried a systematic blue bias of about 3 km/s. That is the one worth
noting: an offset in arcseconds looks like an offset, while an offset in
wavelength looks like a Doppler shift.

Testing

test_inputs_against_astropy_wcs asks astropy.wcs the same question on
all three axes, at four places in the cube. It is built with from_fits
from one file rather than from a time range, so the coordinates and the
keywords they are checked against come from the same file.

The projection is taken off before comparing, since AbstractWcsVector is
the linear part of the transformation and does not apply one. Left in, it
contributes about 2.5e-5 arcsec, which is nowhere near the pixel being
looked for, but taking it out makes the two answers the same answer
rather than nearly the same.

Reverting the fix fails the new test by 9.8e-5 deg, which is 0.353″, one
pixel across the raster. The 16 tests in iris/sg/_spectrograph_test.py
pass with it.

Related

The same bug is open against AIA as sun-data/solar-dynamics-observatory#21,
and was fixed for HMI in sun-data/solar-dynamics-observatory#20. Those
three are the only places in the group's packages that read CRPIX from a
header.

Anything already derived from these coordinates moves by a pixel, so
results built on this will shift.

🤖 Generated with Claude Code

https://claude.ai/code/session_011q4461XE8hCcZCKsViMQC1

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 100.00%. Comparing base (233bcf6) to head (f426345).

Additional details and impacted files

@@            Coverage Diff            @@
##              main       #45   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files           16        16           
  Lines          536       561   +25     
=========================================
+ Hits           536       561   +25     

Flag	Coverage Δ
unittests	100.00% <100.00%> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.