SJICube.wcs is one-based (FITS standard) instead of zero-based (Python/C convention)

[yjzhu-solar]

The WCS information of each SJI exposure is restored in the the auxiliary metadata extension of L2 files using keywords including XCENIX (CRVAL1) and YCENIX (CRVAL2). However, I found SJICube.wcs uses one-based convention (FITS) when I check the consistency between the center coordinate of the SJI FOV given by XCENIX/YCENIX and SJICube.wcs.pixel_to_world(). This is inconsistent with the High-Level API in astropy.wcs and gwcs, which both adopt the zero-based Python/C convention.

irispy_cube = irispy.io.read_files("../../src/IRIS/20221024/1904/iris_l2_20221024_190447_3643101203_SJI_1400_t000.fits")
with fits.open("../../src/IRIS/20221024/1904/iris_l2_20221024_190447_3643101203_SJI_1400_t000.fits") as hdul:
    hdul_wcs_info = hdul[1].data.copy()

print(hdul_wcs_info[0,hdul[1].header["XCENIX"]],hdul_wcs_info[0,hdul[1].header["YCENIX"]])
print(irispy_cube.wcs.pixel_to_world((irispy_cube.meta["NAXIS1"]+1)/2, (irispy_cube.meta["NAXIS2"]+1)/2,0))

returns

-417.15791350482283 193.90387654442202
[<SkyCoord (Helioprojective: obstime=2022-10-24T19:04:49.770, rsun=695700.0 km, observer=<HeliographicStonyhurst Coordinate for 'earth'>): (Tx, Ty) in arcsec
    (-417.1579135, 193.90387654)>, <Time object: scale='utc' format='isot' value=2022-10-24T19:04:49.770>]

Besides, there might be a tiny time lag between the DATE_OBS in the primary extension header and the actual first exposure of SJI. Because the TIME keyword of first exposure is none-zero:

hdul_wcs_info[0,hdul[1].header["TIME"]], hdul_wcs_info[0,hdul[1].header["EXPTIMES"]]

returns

(2.29, 0.999966025352478)

However, the irispy_cube gives the exact same time

irispy_cube.meta["DATE_OBS"], irispy_cube[0:1].time

returns

('2022-10-24T19:04:49.770',
 <Time object: scale='utc' format='isot' value=['2022-10-24T19:04:49.770']>)