search

GeminiDRSoftware / DRAGONS

Data Reduction for Astronomy from Gemini Observatory North and South
Other
27 stars 17 forks source link

The APERTURE table in a 2D longslit image is not readable with IRAF `tread` #226

Open KathleenLabrie opened 3 years ago

KathleenLabrie commented 3 years ago

In IRAF, fxhead shows the APERTURE table as a standard BINTABLE, just like the PROVENANCE table. However, while I can tread the PROVENANCE table, I cannot tread the APERTURE table. tread does not see it at all. I get the "does not exist, do you want to create it" message.

This might indicates that there is something that does not respect the FITS standard in that table.

When loaded with astrodata, the table opens fine as an astropy Table.

chris-simpson commented 3 years ago

This looks like a problem with the default python datatype being 64-bit, which IRAF can't handle. I don't think we ever require 64-bit integers or floats, so there is a solution -- to coerce all numeric Table columns to 32-bit immediately before writing (if possible) -- but, since all other software is happy with 64-bit datatypes, this seems like a poor use of resources.

KathleenLabrie commented 3 years ago

I have confirmed that the table opens fine with astrodata.

I was thinking that this type of conversion to accommodate IRAF is exactly what the makeIRAFCompatible primitive is for. So the best solution is to add the conversion to the existing makeIRAFCompatible primitive. I'm assigning the issue to myself as this is something I can probably take care of when I need a small code task to change my mind.