wcs_project FITS header not updated

[mdecleir]

Hi,

I am using wcs_project from ccdproc to reproject an image to another one (in order to make them the same size).

First, I make a CCDData object from a numpy array (data) and a header:

from ccdproc import wcs_project, CCDData
data_ccd = CCDData(data,header=header,unit="count",wcs=wcs.WCS(header).celestial)

Then, I reproject the CCDData object to a different wcs (from another image) and write the new CCDData object to a FITS file:

new = wcs_project(data_ccd,wcs.WCS(ref_header).celestial)
new.write("test.fits")

This file indeed has the correct WCS information and the header is updated accordingly.
However, if I print a keyword from the header of the new CCDData object, this keyword value is still the same as the old value and has not been updated, e.g.:

print(data_ccd.header['CRVAL1'])
24.208266
print(ref_header['CRVAL1'])
24.222459
print(new.header['CRVAL1'])
24.208266

I would expect the new header to return the new CRVAL1 value, which is 24.222459. Instead it returns the original value, which I don't understand.
However:

hdu = fits.open("test.fits")
print(hdu[0].header['CRVAL1'])
24.222459

I am puzzled why writing the CCDData object to a FITS file updates the header, while the header is not updated just before writing the FITS file.

[mwcraig]

@mdcleir -- thanks very much for submitting this report. You are correct that we ought to be writing the updated values to the header. It may be a week or two until I have time to look into this in detail.

[MSeifert04]

@mdcleir Thank you for the report!

The coordinate-related stuff should be accessed through the wcs attribute. The WCS is properly updated when reprojecting but only inserted in the header when you write the file (because there is no other way to persist the wcs in a fits file except in the header).

I don't really think this is a bug, it's just the way it's supposed to work.

If you construct the CCDData with CCDData.read the wcs-related header keywords are stripped from the header to avoid this problem.

If you really don't want to access the coordinates through the wcs:

• You can easily keep your header in sync by adding data_ccd.header.extend(data_ccd.wcs.to_header()) regularly or
• you could also remove the wcs-related keys from the header (it's a private function currently but you can still call or copy it: https://github.com/astropy/astropy/blob/v3.1rc1/astropy/nddata/ccddata.py#L389-L427).

[mdecleir]

Thank you for your reply. The reason why I cannot use CCDData.read is because my FITS file exists of a datacube of 5 frames in the first extension of the hdulist. So, hdulist[0].data is an array with 5 images. CCDData is unable to handle the dimensions of my FITS file. Therefore, I am reading in the FITS file with astropy, split up the datacube, create a CCDData object for each of the frames, reproject them, and then combine all the frames again in one datacube using astropy. Therefore, I do need the complete header of the original image but with the WCS updated.

data_ccd.header.extend(data_ccd.wcs.to_header())
does not seem to give the desired result. The new wcs is added in the header, but the old wcs is still present and is read by e.g. ds9 as the "real" WCS.
What would you suggest as the easiest solution for my case?

[MSeifert04]

The reason why I cannot use CCDData.read is because my FITS file exists of a datacube of 5 frames in the first extension of the hdulist.

What doesn't work there? Could you open a new issue for that? It should be supported, at least I cannot think of a reason why not.

What would you suggest as the easiest solution for my case?

Not sure, either approach will need some manual handling. I guess the easiest solution would be to split up the datacube into individual images and process them individually.

The alternative is to remove the "old wcs" manually from the header and then update the header with the new wcs.

[MSeifert04]

Maybe it would make sense for ccdproc to provide a function so that users can sync header <-> wcs.

In normal (ccdproc-)cases the header shouldn't contain wcs-related key-value pairs so an automated solution wouldn't make much sense but in cases like this it would make sense to provide the functionality to synchronize them when really needed.