Drizzlepac/HAP: Investigate why an MVM product would be missing CDELT

[stscijgbot-hstdp]

Issue HLA-1564 was created on JIRA by Steve Goldman:

A user from the helpdesk reported that the CDELT1 and CDELT2 were missing from their MVM dataset and they wanted to know the values. These values are the pixel scales. For MVM's we drizzle the constituent products to the same pixel scale 0.12 arcseconds. Investigate why they are missing and decide whether they are worth adding. 

[stscijgbot-hstdp]

Comment by Adrian Lucy on JIRA:

Hi Steve Goldman, just to clarify my perspective, in my view the header is perfectly good and there is no need for a ticket here at all.

CDELTi keywords are not needed when CDi_j notation is used. Matt's email perhaps gets it a bit turned around: the quote about CDi_j notation was me internally saying that we should respond to the external user (which we eventually did) with an explanation of how the header already contains all the information the external user was asking for.

As I put it in that response to the user:

Hi Liam,

Jumping in here to add a couple things, as an overzealous member of the FITS fan-club here at MAST (and apologies, I think one of Matt's emails was meant to be responding to me internally).

Like Matt said, for the example file you pointed out, the documentation indicates 0.12 arcsec/pixel for the coarse-grid products of which your example file is a member (hst_skycell-p2128x19y06_wfc3_ir_f160w_coarse-all_drz.fits).

Looking at that file's header, we see: CD2_2 = 3.33333333333333E-05 CD2_1 = 0.0 CD1_2 = 0.0 CD1_1 = -3.3333333333333E-05

So this file uses the CDi_j formalism for the WCS linear transformation matrix for transforming pixel coordinates j to intermediate world coordinates i, which is an alternative to PCi_j formalism; and both CDi_j and PCi_j replaced the old CROTAi formalism for describing the coordinate rotation. CDELTi is used by PCi_j, and is allowed but ignored by CDi_j. You can read more about these formalisms in Section 8 of the FITS Standard (https://fits.gsfc.nasa.gov/standard40/fits_standard40aa-le.pdf) and in Greisen & Calabretta 2002 (https://www.aanda.org/articles/aa/pdf/2002/45/aah3859.pdf).

That is to say, it’s normal and expected for a WCS that uses CDi_j to omit CDELTi keywords, and information about the pixel scale is embedded in the CDi_j keywords. One has to go a bit far afield to find a reference that explains the conversion explicitly instead of just leaving it as an exercise for the reader, but a nice explanation can be found in Section 6.3.3 of this old IVOA draft: https://www.virtualastronomy.org/AVM_DRAFTVersion12_rlh02.pdf (or for a history lesson, see Hanisch & Wells 1988, bottom of page 4: https://lweb.cfa.harvard.edu/~jzhao/SMA-FITS-CASA/docs/wcs88.pdf). In converting to PCi_j or CROTAi notation, you can calculate the magnitudes of new* CDELTi corresponding to the plate scale as follows:

|CDELT1| = sqrt((CD1_1)^2 + (CD2_1)^2) |CDELT2| = sqrt((CD1_2)^2 + (CD2_2)^2)

For an image without too much stretch or skew, these will be equal or nearly equal. To get the signs you would need to calculate the determinate of the matrix, but at that point it’s probably better to rely on programmatic tools like astropy.wcs or wcslib.

*(I’m being a little careful with my words, since another way to look at this is that CDi_j is equivalent to PCi_j if CDELTi were artificially set to 1 instead of the plate scale.)

In the example file above, this means that: |CDELT1| = sqrt((-3.33333E-05)^2 + (0)^2) = 3.33333E-05 degrees = 0.12 arcsec |CDELT2| = sqrt((0)^2 + (3.33333E-05)^2) = 3.33333E-05 degrees = 0.12 arcsec

So the header WCS says 0.12 arcsec/pixel, which matches the plate scale we expect from the documentation.

I hope that’s helpful! Adrian Lucy

[stscijgbot-hstdp]

Comment by Steve Goldman on JIRA:

Adrian Lucy Okay thanks for clearing that up. I'll go ahead and close this ticket.