[Aavso-photometry] FITS Keyword List

[Michael Newberry]

Brian,

I know the verifier you are talking about. But it is the wrong tool here,
because it does not address the problem we are talking about---or at least
the problem I *thought* we were talking about. The verifier checks for
structural problems in the header, like whether data begins on a 2880 byte
boundary. It also checks whether the formats of known mandatory keywords are
met. For example, does NAXIS have an integral numeric value (correct) or a
letter (incorrect)? It cannot check for such things as whether GAIN or EGAIN
is used, or whether OBJRA is being used for the right ascension of the image
even though the RA keyword already exists for that purpose. Likewise, it
cannot test for something as simple as using EXPOSE or EXPOSURE (both
incorrect) instead of EXPTIME (correct) to hold the exposure time. If it
were to see EXPOSE. then it would just say "EXPOSE is not a mandatory
keyword name, I don't know what it is used for and so I'll ignore it, but
the numeric format looks OK." For the image using EXPOSE for the exposure
time, "standard" software would have trouble. That's not a flaw in the
verifier, but just a limitation of what can be verified in a FITS image.
This happens because FITS format has a small core and is extensible, thus
relying on a set of "conventional" keywords that carry most of the useful
information.

What I thought we were talking about was what "dictionary" of keyword names
would be used to signifiy specific quantities in the header. This is
pecisely why I posted the keyword table from the Mira documentation as an
example of a pretty well worn set of keyword names in common usage.

Micahel Newberry


----- Original Message ----- 
From: "Brian D. Warner" <brian at minorplanetobserver.com>
To: <aavso-photometry at mira.aavso.org>
Sent: Friday, January 04, 2008 3:08 PM
Subject: [Aavso-photometry] FITS Keyword List


> Michael,
>
> The one FITS standard has become a pretty well universally adopted 
> convention.
> Regardless of how well-adopted that convention is, that does not equate to
> a formal standard.
>
> Any claims by any vendor should more carefully qualify what is meant about
> compliance. If it follows a convention, that is what should be stated, not
> that it's in compliance with _the one standard._
>
> I'll go back to my original contention that if any image from any package 
> can
> pass the test on
>
>  http://fits.gsfc.nasa.gov/fits_verify.html
>
> (not NOFS, as I incorrectly stated, but NASA/GSFC FITS Support page), it 
> should be
> considered "compliant" for now and that the software is also "compliant." 
> That is
> a formal test that can be independently validated by anyone.
>
> Arne proposed that he work with vendors to adopt some sort of rules. 
> That's fine,
> but unless something special happens, it looks to be just another 
> convention,
> maybe the "AAVSO FITS convention." That's fine, too, just as long as it's 
> recognized
> as such and not some formal standard against which software is claimed to 
> comply and
> so
> imply suitability or usefulness.
>
> Unfortunately, without the making of a true standard, the issue of 
> compliance will
> never be resolved (that assumes people will honor that standard). Adding 
> yet another
> convention just means more work, headaches, and tech support issues for 
> vendors and
> end-users.
>
>
> Clear Skies,
> Brian D. Warner
> Palmer Divide Observatory/Space Science Institute
> http://www.MinorPlanetObserver.com
>
> Collaborative Asteroid Lightcurve Link (CALL)
> http://www.MinorPlanetObserver.com/astlc/default.htm
>
> _______________________________________________
>
> Aavso-photometry mailing list
> Aavso-photometry at mira.aavso.org
> http://www.aavso.org/mailman/listinfo/aavso-photometry
>
>