bugGNU Astronomy Utilities - Bugs: bug #58363, Cite exact parts of FITS standard...

 
 

You are not allowed to post comments on this tracker with your current authentication level.

bug #58363: Cite exact parts of FITS standard or CFITSIO about primary HDU

Submitter:  Mohammad Akhlaghi <makhlaghi>
Submitted:  Wed 13 May 2020 12:55:25 AM UTC
   
 
Category:  Libraries Severity:  3 - Normal
Item Group:  Addition(s) Status:  Fixed
Privacy:  Public Assigned to:  makhlaghi
Open/Closed:  Closed

Sat 23 May 2020 07:42:29 PM UTC, comment #3: 

The correction in the previous commit doesn't cause confusions any more and there was no discussion afterwards. So I am closing this bug.

Mohammad Akhlaghi <makhlaghi>
Group administrator
Wed 13 May 2020 04:35:16 PM UTC, comment #2: 

The error message has been updated, what do you think now?

Based on the parts I cited in the first message, I think we can safely say that the standard "stipulates" this scenario (as mentioned in the new error message).

You are right, recommendation is a strong word, suggesting that if a file doesn't follow it, it doesn't follow the FITS standard.

But as the cited parts show, the authors of the FITS standard did stipulate/acknowledge that this scenario (where the primary HDU has no data) is a possibility.

Mohammad Akhlaghi <makhlaghi>
Group administrator
Wed 13 May 2020 06:15:11 AM UTC, comment #1: 

I implemented 80% of the FITS 4.0 standard a few months ago in Scala language (https://www.scala-lang.org/) and I don't remember any recommendations on how to organize the HDUs.  Hence, the message was strange to me.

In fact, I think that any recommendation about this should be explicitly stated in section '3. FITS file organization' but I couldn't find it.

I agree that gathering the metadata on the primary HDU makes sense, but I don't think it's part of the standard.


Rafael Morales <rmorales>
Wed 13 May 2020 12:55:25 AM UTC, original submission:  

It was recently mentioned in bug-gnuastro@gnu.org that the statement "Gnuastro leaves the first HDU blank (with no data) and writes the outputs in the second HDU. " is not actually recommended in the FITS standard (as suggested when the error message).

This is the full printed message when the input only has one extension, but the program expects data in the second extension. (of course, as mentioned in the error message, this "expectation" can easily be changed with a '-h0' option):

"FOOTNOTE -- When writing a new FITS file, Gnuastro leaves the first HDU blank (with no data) and writes the outputs in the second HDU. In this way the keywords of the the first HDU can be used as meta data of the whole file (which may contain many extensions). This is the recommended way in the FITS standard. As a result, Gnuastro's default HDU to read an extension in a FITS file is the second."

I don't have too much time right now of precisely find the exact place I got this recommendation from (I should have mentioned it when I made the statement, but a fast look points me to these places below (from the FITS 4.0 standard, Language-edited document publication date: 2018 August 13):

  • In Section 2 (Definitions, acronyms and symbols), for "primary header" it is stated that: "The first header in a FITS file, containing information on the overall contents of the file (as well as on the primary data array, if present)."


  • In Section G.1.1 (Recommendations for application writers), of the five scenarios mentioned, 4 of them have an empty primary HDU.


  • In Appendix K (Header inheritance convention), where they say that if an 'INHERIT' keyword is present in a header, the application should go looking in the primary HDU. Although its not officially in the standard, it is mentioned here as a "convention". This again implies that the primary HDU is mainly allocated for all the extensions.


I'll have to find the reference for this later, but I remember reading somewhere that the fact that images are allowed in the primary HDU is only for historical reasons. Later, when they added Tables to FITS, to avoid the same mistake, they didn't allow tables in the primary HDU.

It also makes very nice sense: the primary HDU is for the meta data in all the extensions of the file, each extension then has its own unique metadata. Having images in the second extension, also allows a unified interface for programs that accept tables or images (for example Gnuastro's Statistics program.

This is filed as a bug because any user who confronts this message expects proper citation of the standard and we should find a way to cite it clearly.

Mohammad Akhlaghi <makhlaghi>
Group administrator

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by rmorales (Posted a comment)
  • -email is unavailable- added by makhlaghi (Submitted the item)
  • -email is unavailable- added by makhlaghi
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

     

    Follow 4 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2020-05-23 makhlaghi StatusNone Fixed
        Assigned toNone makhlaghi
        Open/ClosedOpen Closed
    2020-05-13 makhlaghi Carbon-Copy- Added -email is unavailable-

    Back to the top

    Powered by Savane 3.13-d3ae.
    Corresponding source code