Open giordano opened 5 years ago
Multi-extension FITS files often use this style of "header-only" primary HDU, for metadata that applies to all the extensions in the file. It is also used for FITS files containing only table HDUs, as the first HDU cannot be a table HDU.
It's not clear that a separate subtype is necessary for the "primary HDU." As prior art, the Python package fitsio (on which the FITSIO.jl API is based) does not have a separate type for the primary HDU. The primary HDU is simply the first HDU (with the additional restriction that it can't be a table HDU). So it can only be an ImageHDU (with or without a data segment). Personally, I find this helpful: when you see that it is an ImageHDU
, you immediately know that there's nothing special about this first HDU (other than the fact that it perhaps contains no data; but this can actually be the case for any ImageHDU!).
I do think it would be helpful to have a quick method for testing whether an ImageHDU contains data, and also helpful to print the dimension information in show(::FITS)
, as astropy.io.fits does.
Without looking at the issue, I suspect that the right approach in JuliaAstro/AstroImages.jl#9 should be to look for the first ImageHDU with a non-empty data array. (And perhaps specifically a 2-d data array at that!).
Without looking at the issue, I suspect that the right approach in JuliaAstro/AstroImages.jl#9 should be to look for the first ImageHDU with a non-empty data array. (And perhaps specifically a 2-d data array at that!).
I didn't look into how Astropy detects a PrimaryHDU, but I was thinking about something like this.
For the record, also fv
indicates the first extension as "Image", however it is named "Primary", instead FITSIO.jl
leaves it unnamed, Astropy calls it "PRIMARY".
There is another usage of the Primary HDU that I have found sometimes in astronomical and cosmological codes: using it to encode some complex metadata in a high-level format (XML, JSON, YAML) that are associated with the file as a whole.
I heard this technique during a discussion at ADASS2016 («The future of FITS», if I remember correctly). I have used it several times, the idea is to use something like this:
import JSON
import FITSIO
# Encode some complex structure
s = JSON.json(Dict(:a => 10, :b => ["foo", "bar"]))
f = FITSIO.FITS("newfile.fits", "w");
# Convert the string into an array of bytes
write(f, convert.(UInt8, collect(s)))
close(f)
Don't know how much this trick is widespread, however. Maybe AstroImages.jl could just check that the image in the PrimaryHDU has more than one row.
A side note about "the future of FITS": there is already a julia package to work with ASDF files: https://github.com/eschnett/ASDF.jl
Currently, we have the following HDUs:
However the FITS expects at least one other type, "Primary HDU", see https://fits.gsfc.nasa.gov/fits_primer.html.
One example of FITS file with a Primary HDU has been reported at https://github.com/JuliaAstro/AstroImages.jl/pull/9:
EUVEngc4151imgx.fits
.FITSIO.jl
shows the following table:instead Astropy reports: