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

[Lee Kelvin]

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

I personally favour the latter option of the two you present, adding all
keywords which do not already exist in the header. In my own efforts writing
FITS read/write software for the R astro package
<https://cran.r-project.org/web/packages/astro/index.html>, we arrived at a
similar conclusion. 

The safest way ahead would be to allow WCSLIB to construct a basic FITS header
output, and then propagate any additional header keywords from the original
FITS file which do not already have a match in the proto-output file. 

Many software packages do this as default, so I would have this option enabled
by default too. Personally, and knowing the value of FITS header keywords for
science, I would not make this an option. Rather, I would force this behaviour
always. 

FITS header keywords not supplied by WCSLIB but rather propagated through from
the original header could be left beneath a COMMENT tag with the comment along
the lines of 'Propagated FITS keywords below', or similar.

However, some care must be taken to avoid FITS header keyword name clashes. It
is inevitable that new WCS header keywords will clash with the old, previous
WCS header keywords. This is as expected, and defaulting to the new value when
a clash exists is the desired option. The biggest source of potential clash
comes from GNU Astro value-added header keywords. It is not inconceivable that
value-added GNU Astro header keywords (such as 'INF_1' after using ImageWarp)
may already exist in the original FITS file, e.g., from a previous invocation
of ImageWarp. In a scenario such as this, which header keyword gets the
preference? My instinct is to lean towards the original, but it would be nice
to have the new information also. To achieve this, a number could be appended
to output GNUAstro value-added keywords to avoid keyword name clashes?

Perhaps the output FITS header should be constructed like this:
* WCS keywords: always take new keywords over old
* GNUAstro keywords: append _n to all value-added GNUAstro keyword outputs to
avoid clashes (also has the bonus of revealing how many times a GNUAstro
operation has been performed on the file)
* Propagated keywords: always take all old keywords which do not have a match
in any of the two classes above.

Keen to hear your thoughts, 

Regards, 
Lee Kelvin


    _______________________________________________________

Reply to this item at:

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

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