gwcs

gwcs copied to clipboard

Add methods to_fits() and to_asdf().

Might be worth considering just a write method and going through Astropy's general I/O framework. For to_fits() and to_asdf() those could be fine too but they would just be wrappers around the former.

The advantage to this, less than writing, would be in reading. One could run WCS.read(filename) and the user doesn't have to care what the actual file type is if it's a supported format.

Just to be clear, what would to_fits do? Would it write a FITS file? Return an HDU? Return an Astropy Header object?

I can see three options:

• Write out a FITS file which wraps the ASDF object as an extension. I'm not sure that's very useful.
• Write out a FITS file with the conventional WCS object (using astropy's to_header() or to_fits() depending on what is in the WCS) or an approximation of the transform (as you mention in #99 ).
• I need to read again about the details of the FITS -TAB convention and see if it can be useful in this case.

I would think it's useful to write out a FITS WCS (ie. option 2 or 3) as you propose above, but also encode the full representation somehow (it can be more obscure), so that you can read the data back in from the FITS file without loss of information. Of course, this may raise the painful issue of representations getting out of sync, but it solves a couple of practical problems (including visualization with existing tools) and would work as long as you don't do anything unusual... Off the top of my head, you could include a "WCS checksum" and refuse to re-load the "full" WCS encoding if the FITS version has been user-modified; if that's not good enough, the user has to make their modifications with gwcs instead of editing the FITS headers (which re-generates the checksum). Or you could perhaps declare the FITS representation read-only and warn people not to mess with it.

Maybe this is more complexity than you want, but I think it would be nice to have. It might be tough to persuade Gemini to use ASDF in the near future, so we'll need some way to serialize gwcs in FITS if we use it in the meantime. I probably need to make a bit more progress on a little proof-of-concept using gwcs that I started earlier in the year before working on I/O, but it's something I might be able to help with if this is still pending, say, a few months from now.

Regarding going through Astropy's general I/O framework, @embray, do you mean via NDIOMixin.write()? Or some WCS.write() method that modifies an extension header (perhaps having to re-write the whole file each time)? Actually, your read() example suggests the latter. I think it's important to have an API for encoding the FITS & ASDF headers in memory, since Astropy I/O currently deals only with a single set of FITS extensions, whereas we need to be able to write files containing some number of NDData instances (each with a wcs attribute), which currently requires a 3rd-party package, while modifying an existing thing on disk N times is at best inefficient. I would see the wcs object as something associated with an NDData instance (like general meta-data), more than a thing that you want to read & manipulate separately. I would like to be able to hook into a "write this this gwcs object to this FITS/ASDF header object" in my own write() method.

This ticket is now being tracked at AL-76

I had forgotten having this discussion, but in AstroData we settled on writing a WCS, N FITS ASCII table extension containing the ASDF representation of the WCS that goes with the corresponding SCI, N, VAR, N etc. from the same NDData instance: https://github.com/GeminiDRSoftware/DRAGONS/blob/e1e69316460b38c7e7815f51cfc66f26b809d878/astrodata/fits.py#L718-L831.