1. Stefan B Avatar Stefan B
  2. nina
  3. NINA
  4. Issues

Nightly 065: Fits tags OBJCTRA and OBJCTDEC are not filled when slewto AZ/ALT was used

Issue #837 resolved
Ruediger created an issue

Hello,

I have just noticed that the fits header tags OBJCTRA and OBJCTDEC are set to ‘00 00 00’ when slew ALT/AZ was used, though the mount reports that crucial data.

This is a problem when creating celestial models or doing mount stability tests (e.g. flexure, settle time) where you move to constant and repeating fixed positions via ALT,AZ and then solving the the images in batch mode. Then this crucial information is missing and the delta position cannot be calculated..

Please populate fields whenever the data from mount is available.

Thank you!
Rüdiger

‌

‌

Comments (24)

  3. Ruediger reporter

    Thanks Stefan, I am currently in discussion with Han (ASTAP author) because he is referencing to these fields and noticed they are empty and causing some issue. I have sent him the link to this issue, so we can find a solution.

    Thx! Rüdiger

  4. Han K

    Hello Stefan,

    Having the mount position documented with keyword RA and DEC is no problem but writing zeros to OBJECTRA and OBJECTDEC is the problem. This give two conflicting RA&DEC values. At the moment ASTAP reads both and keywords OBJCTRA, DEC comes at last giving the zero problem. I can probably fix that by swapping the reading of the keywords.

    SBIG and MaximDL are using OBJCTRA and OBJCTDEC for center of image and not keyword RA, DEC. It would be more elegant to skip keyword OBJCTRA and OBJCTDEC if no information is available. Would that be possible?

    SGP fills both keywords with the same value but then would be less elegant then skipping the keywords if no object is specified.

    MaximDl definitions:

    https://cdn.diffractionlimited.com/help/maximdl/FITS_File_Header_Definitions.htm

    Thanks, Han

    ‌

    ‌

  5. Dale Ghent

    There is no real standard around these keywords other than RA and DEC. My interpretation is that the “object RA/DEC” keywords refer to the coordinates of the object of interest in the frame. The RA and DEC keywords refer to the actual location that the telescope is pointing. The two can be different, because the object of interest (OBJCTRA and OBJCTDEC) may not always be in the center of the frame (RA and DEC)

    The MaximDL definitions you link to mention no such requirement that the OBJCTRA and OBJCTDEC keywords reflect the center of the image, only that they reflect the “Right Ascension/Declination of object being imaged.” Well, the “object being imaged” may not always be at the exact center of the frame.

    Over at the FITS standards site, they have a Dictionary of Commonly Used FITS Keywords and the definitions of RA and DEC is very similar to OBJCTRA and OBJTDEC in that they also define their values to be “the object” rather than the center of the frame. If we want to use a keyword pair that is specifically for recording where the instrument is pointing, it looks like we should use the RA_PNT and DEC_PNT keywords, the definitions of which explicitly state that they are for recording where the instrument is pointed, regardless of the object’s coordinates.

    So it seems we should do the following:

    1. OBJCTRA/DEC remain the same and reflect the coordinates of the object of interest, not necessarily where the telescope is pointing
    2. RA and DEC are removed or have the same value as OBJCTRA and OBJCTDEC respectively
    3. We add new keywords RA_PNT and DEC_PNT to record the coordinates that the mount (telescope) is pointing at per the Dictionary of Commonly Used FITS Keywords

    ‌

  6. Ruediger reporter

    respective 2: I have a very bad gut feeling about removing RA and DEC. I think that may cause some nasty side effects with other programs. Better make them equal.

    respective 3: Adding the new keywords sounds reasonable.

    Rüdiger

    ‌

  7. Han K

    The OBJCTRA, OBJCTDEC are akward because they are strings but almost all astronomy program use them since it was standardized by SBIG as center of the image in 2003. See attached.

    SBIG is now part of Difraction Limited (MaximDL). There is a link on their side but it not working at the moment.

    RA, DEC keywords are used by many program because they are floats and documented at Nasa FITS keyword page.

    RA_PNT and DEC_PNT are never used in practice. I would not advice to use these keywords because no other program will be able to read them. There are already enough keywords around.

    The problem is the discrepancy in the header between two common keywords both used for mount positions. A value of ‘00 00 00’ is wrong. If no information is available, then the keyword should not be there.

    Han

    ‌

    ‌

  8. Stefan B repo owner

    Well if OBJECTRA/DEC are truly the center coordinates, they have to be removed completely by the N.I.N.A. file writer, as we don’t platesolve the image and don’t know for sure what those coordinates are.

  9. Dale Ghent

    But wait, the Diffraction Limited document you linked does not say anything about OBJCTRA and OBJCTDEC representing the center of the frame, only “the object”. The Diffraction Limited document even says “Note: this is an approximate field center value only.” The SBIG document says “center of image”. These two documents contradict each other. The meaning is of the OBJCT* keywords is ambiguous.

    And if RA and DEC are essentially synonyms of OBJCTRA and OBJCTDEC due to their definition of being the coordinates of “the object”, not the center of the frame, then that leave no keywords that record the actual pointing coordinates of the telescope, as claimed by the mount driver. This is why I suggest the use of RA/DEC_PNT as they are defined explicitly for this purpose in the FITS Standard’s dictionary of common keywords. Who is to say that they are irrelevant? They are in the standard and have a defined purpose…

  10. Ruediger reporter

    But at least we can agree on, if no object is defined, to set it to 00 00 00 is definitely wrong. Since 00 00 00 is actually a valid date, but does not represent the object in that case. The smallest common denominator would be not write it to the header.

  11. Stefan B repo owner

    yea if no object is available this keyword should be skipped. that’s something to fix.

  12. Han K

    Most programs use keywords RA, DEC for mount position. Some OBJCTRA, OBJCTDEC. The keywords RA, DEC are preferred since they are floats.

    After SOLVING the “reference point” of the image is defined by CRVAL1, CRVAL2. Also by astrometry.net. So there is NO NEED for a center of image keywords.

    “Center of image” is pre-dating astrometric (plate) solvers. Just read it as mount position.

    E.g.the ESA standard (please ignore or see it as mount position):

    / RA of center of image in decimal degrees

    https://indico.esa.int/event/124/attachments/711/771/06_ESA-SSA-NEO-RS-0003_1_6_FITS_keyword_requirements_2014-08-01.pdf

    ‌

    ‌

    ‌

    ‌

  13. Dale Ghent

    Yes, after solving the WCS keywords are definitive for the center of image. However that’s a separate operation, after an image is created. For any given image, it might not be solved at all. So there must be an appropriate keyword to record the nominal RA and DEC of its axes. Looking over the FITS dictionary of keywords, this would be RA_PNT and DEC_PNT. RA and DEC should be the object of interest. OBJCTRA and OBJCTDEC, by their keyword name alone, would imply “object” as well, not center of image (the former set being real numbers, the latter set being string HMS/DMS notation, ugh)

    I really don’t like the MaximDL, uh, “extensions”, because they themselves are inconsistently defined (see also: the original SBIG definition of OBJCTRA and OBJCTDEC) but also inconsistent with their own “peer” keywords. For example, this except from the MaximDL document:

    • OBJCTALT – nominal altitude of center of image             
    • OBJCTAZ – nominal azimuth of center of image
    • OBJCTDEC – Declination of object being imaged, string format DD MM SS, if available. Note: this is an approximate field center value only.
    • OBJCTHA – nominal hour angle of center of image
    • OBJCTRA – Right Ascension of object being imaged, string format HH MM SS, if available. Note: this is an approximate field center value only.

    The bolded parts are what I’m pointing out in this regard. OBJCT* keywords other than OBJCTRA and OBJCTDEC refer directly to “center of image”, but OBJCTRA and OBJCTDEC are noted to not necessarily reflect the center of the image. Sigh. I can’t seriously consider this set of keywords to be a “standard” by any measure. This metadata schizophrenia is a single reason why FITS should be toss in the can and people move on to XISF.

  14. Han K

    All these descriptions are equivalent to “mount position” What else would they have written to the FITS header 20 years ago?

    For compatibility reasons the best strategy is to use keywords which are already used by other programs.

    XISF still uses the same keywords packed in XML.

    ‌

  15. Dale Ghent

    XISF has a facility in its header metadata for embedding traditional FITS keywords, but this is a facility that is provided for freeform “FITS style” header data. For defined, structured metadata, XISF defines Image Properties which may record the observation and instrument data. The definitions for these various properties are very explicit and, IMO, should always be preferred as the source of information over any embedded FITS keywords, especially due to the ambiguity around the FITS keywords we have talked about.

  16. Ruediger reporter

    Another important question came up in the internal discussion:

    When storing the J2000 coords in the header, how are they calculated? Via True or Mean equinox of date? How are the J2000 coords calculated from the mounts JNOW coords? Is except precession also nutation and aberration considered?

    These questions came up when comparing coords in ASTAP.

    ‌

  17. Han K

    The question is:

    If a mount communicates with Nina in Jnow=True equinox of date, for the conversion to J2000 is a nutation and aberration correction included?

    So value 1 in

    https://ascom-standards.org/Help/Platform/html/T_ASCOM_DeviceInterface_EquatorialCoordinateType.htm

    I’m pretty sure the answer in no but that is the question. If no then the mount (10micron) can be better set to communicate in J2000. No conversion errors.

    Most conversion is simple “mean equinox of date” to J2000. Not “true equinox of date” to J2000.

    Han

    ‌

  18. Ruediger reporter

    Hi Stefan, Hi Dale,
    is aberration and nutation considered or only precision? We need the info, because if not considered we have to find a work around to get precise data. This could be also an reason why centering sometimes never is convergent, since error margin is lower than the conversion error. Thank you!

  25. Log in to comment
Assignee
–
Type
bug
Priority
major
Status
resolved
Component
User Interface
Version
–
Votes
0
Watchers
1
Jira: the preferred issue tracker for Bitbucket. Join the team!