gnuastro-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Lee Kelvin
Subject: [gnuastro-devel] [task #14315] Propagate all FITS header keywords into output FITS files
Date: Mon, 23 Jan 2017 17:27:25 +0000 (UTC)
User-agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.87 Safari/537.36

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

Hi Mohammad,

A few thoughts on your comments.

> 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). 

Whilst I appreciate your desire to keep FITS files simple and as small as
possible, from an end-user perspective I anticipate that this approach will
cause much confusion. I would strongly advocate for all header keywords to be
propagated forwards instead as default.

Many other software packages propagate all FITS header keywords in this
manner. For example, the NASA HEASARC program 'fitscopy' may be used on the
initial 'input.fits' file I provided at the start of this thread to crop a
small 1x1 pixel region from the original 3x3 image using the command:


fitscopy input.fits[1:1,1:1] output.fits


In this command, the relevant CFITSIO header keywords are changed
(NAXIS1/NAXIS2), as expected, and the scientific header keyword TEST is
automatically propagated. It is up to the end-user to remove that header
keyword after-the-fact should they see fit. STScI's 'imcopy' also operates in
the same manner. They both operate this way because it is easier to remove
surplus information than it is to add missing information.

I think operating in this fashion is the natively expected behaviour, however,
I wanted to check this in a different field. I took a photograph on my phone,
uploaded the JPEG image to my computer, and opened it using the image
processing software GIMP. I cropped a small region, and exported the output
JPEG. On opening the cropped image, all of the extra metadata (aperture,
exposure, focal length, flash, etc...) had all made it through to the new
output image.

> So your suggestion to add already existing keywords as `COMMENT' keywords is
indeed very interesting.

Just to clarify what I mean here, I do not mean to add existing keywords as
COMMENT keywords. The keywords should be kept intact wherever possible, to aid
in pipeline processing. A COMMENT tag can be used to delineate between old
header keywords and new ones. For example, a file prior to image warping may
have a header which looks like this:


SIMPLE  = T
BITPIX  = 16
NAXIS   = 2
NAXIS1  = 3
NAXIS2  = 3
EXTEND  = T
...
TEST    = 'VALUE   '


and afterwards may have a header which looks like this:


SIMPLE  = T
BITPIX  = 16
NAXIS   = 2
NAXIS1  = 1
NAXIS2  = 1
EXTEND  = T
...
TEST    = 'VALUE   '
COMMENT 
COMMENT Entries below from GNUAstro ImageWarp
COMMENT 
INF_1   = ...
...


Once a standard for propagating through existing header information has been
agreed upon, then would be a good time to tackle the issue of keyword name
clashes more closely.

Regards, 
Lee Kelvin


    _______________________________________________________

Reply to this item at:

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

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]