GNU Astronomy Utilities - Tasks: task #14340, Defining arbitrary variable and...
You are not allowed to post comments on this tracker with your current authentication level.
task #14340: Defining arbitrary variable and its value in FITS headers
Submitter: | Mohammad Akhlaghi <makhlaghi> | ||
Submitted: | Tue 31 Jan 2017 12:09:49 AM UTC | ||
Should Start On: | Mon 30 Jan 2017 03:00:00 PM UTC | Should be Finished on: | Mon 30 Jan 2017 03:00:00 PM UTC |
Category: | All Gnuastro | Priority: | 5 - Normal |
Item Group: | Enhancement | Status: | Postponed |
Privacy: | Public | Assigned to: | None |
Percent Complete: | 0% | Open/Closed: | Open |
Effort: | 0.00 |
Tue 31 Jan 2017 05:17:38 PM UTC, comment #5: |
Mohammad Akhlaghi <makhlaghi> |
Tue 31 Jan 2017 05:10:20 PM UTC, comment #4: Thank you very much Boud and Lee for the great comments, I personally subscribed to the fitsbits mailing list and will post issues I have with the standard there. Until now, I have tried really hard to do everything with the existing conventions and make as little change as possible. Fortunately Lee's suggestion was the solution :-).
|
Mohammad Akhlaghi <makhlaghi> |
Tue 31 Jan 2017 04:58:09 PM UTC, comment #3: Boud posted the following message to this task but directory to the gnuastro-devel mailing list. So I am also sending it here for the record.
|
Mohammad Akhlaghi <makhlaghi> |
Tue 31 Jan 2017 11:49:24 AM UTC, comment #2: Apologies, the link in my previous post seems to be broken. Here it is again, for reference: https://heasarc.gsfc.nasa.gov/docs/software/fitsio/c/f_user/node28.html |
Lee Kelvin <leeskelvin> |
Tue 31 Jan 2017 11:47:55 AM UTC, comment #1: Hi Mohammad,
|
Lee Kelvin <leeskelvin> |
Tue 31 Jan 2017 12:09:49 AM UTC, original submission:
It is very important for reproducibility that the programs which produce FITS images also add all their input option values into the produced extension. One of the reasons this is currently not done was that the option names can be arbitrarily long and have many types. While the FITS keywords have a strict limit on their length and there is nothing about specifying a type. So there was no robust way to keep this information.
|
Mohammad Akhlaghi <makhlaghi> |
No files currently attached
Depends on the following items: None found
Items that depend on this one: None found
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.
Powered by Savane 3.13-d3ae.
Corresponding source code
Sorry, I meant the `gal_data_string_to_number' function of lib/data.c. This function will determine the type of a number written as a string and store it automatically. So we won't need to explicitly keep the type of the variable in the header keyword. If the returned pointer is NULL, we know the value was a string and we can store it as such.
`gal_data_string_to_type' (that I mentioned in the previous comment), takes a given type and reads the string in that, so it isn't useful for this job.