[gnuastro-devel] [task #14315] Propagate all FITS header keywords into output FITS files

[Mohammad Akhlaghi]

Follow-up Comment #3, task #14315 (project gnuastro):

Thanks, I agree, the second/latter method (where the "Header" program would be
in charge of propagating headers from one or multiple files into another file)
is a much better method, and is in-line with the modularity principle.

Ultimately, each program should only produce the raw header keywords that are
directly related to it's processing and the minimum required FITS/WCS keywords
(written by CFITSIO and WCSLIB, not taken directly from the input). 

Science-related keywords, are only relevant/useful at higher-level than any
single program. Whether they should be added or not is a choice by the
science-case the data is meant to be used for. They are also commonly only
necessary in the final data product of a research process, not in all the
intermediate files. 

But ultimately, even if it is directly available only in the Header program,
this feature will be implemented as a library function, so people can also
implement it directly in their own separate programs, or if there is enough
demand, it can be added as a common option to all programs (the first option,
but will be disabled by default).

The Header program works at a lower level than CFITSIO or WCSLIB. For example,
you can even delete a mandatory FITS header with it: Header will do the job,
but your FITS file will be unreadable! So as far as the Header program is
concerned, it only sees keywords that exist in the input and those that are
only available in the reference/other file+extension. 

The name-clashes you mentioned are indeed important. In the implementation,
atleast we can account for those in the FITS standard manually (for example
the case for RADECSYS and RADESYS that you mentioned in bug #50073).

So your suggestion to add already existing keywords as `COMMENT' keywords is
indeed very interesting. But just at the top of my head, I feel this might be
too much: if a header value has changed, adding it has the potential to
confuse people more than inform them. If the user feels it is very important
to have the old values, they can define their own conventions for old values
and use Header to add them individually (easily done in a script) to add them
in what-ever way they like. The Header program has many ways to write/update
header keywords.

All the keywords from another file+extension can be added under a title like "
     \ keywords from XXXXX.fits (hdu: YYY) " (the same way WCS keywords are
separated from program-specific and also version keywords). This way, headers
from multiple files can even be merged into the final output.

I think this classification of the header keywords would also fix the problem
you mentioned on the value-added keywords. As you suggested, repeated keyword
names and their value can be put in a COMMENT keyword, so the information
isn't lost and there is also no conflict with (possibly) existing keywords of
the same name. 

Unfortunately the FITS standard puts a limit of 8 characters on the keyword
names, so reserving two characters for `_n' suffix would make them even more
cryptic than they already are and hard to read/understand/use. If the problem
can be addressed with the classification of headers by the file+extension they
originated from, that might be a better solution.

Reproducibility information (how the raw data was processed to produce an
output) is indeed very important, but that information is much better/usefully
preserved in scripts/Makefiles rather than FITS headers. I have been thinking
about this for some time, so I just defined task #14319 as a starting point
for that discussion. Implementing something like what is proposed there will
remove the need to keep many extra header keywords. However, it won't remove
the need to propagate some keywords in the final output, so it is independent
of this task.

But please share you thoughts on that task too ;-)...

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/task/?14315>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/