The latest version of Pixinsight rejects image files with the message:
*** Error: Parsing SITELAT FITS keyword: Parsing sexagesimal expression: Parsing 64-bit floating point expression: conversion error:
*** Error: Parsing SITELONG FITS keyword: Parsing sexagesimal expression: Parsing 64-bit floating point expression: conversion error:
*** Error: Parsing RA FITS keyword: Right ascension value out of range: ‘168.68270980429’
“These are invalid values for the SITELAT and SITELONG keywords. See the SBIG proposal for FITS keyword extensions document. The expected format for these nonstandard keywords is the same as OBJCTDEC, that is, ‘DDD MM SS.sss’. Another example of the endless universe of FITS interoperability problems.”
Thanks - but I think you can only edit individual files.
For example, in the latest project I have 235 lum, and 60 each R, G, and B. Way to many to hand edit.
Also the “black block” doesn’t show in FITS header reader which appears to read info correctly.
It puts me right off PI. Changing how they parse the data and then expecting everyone else to change seems pretty arrogant to me.
It isn’t as if it would be difficult for them to implement something helpful. The data is in the form of a string containing up to three decimal numbers, each separated by at least one non numeric character. Parsing this is the sort of thing that should appear as an exercise in a programming101 class.
The challenge isn’t the separators, it’s managing the negative sign for small negative values. What does “00 -30 0” give? Or “-0 30 30”? Extra marks for “0 0 -30”. And can the minute or second values be 60 or more? “0 60 0” is a perfectly valid angle (1 degree) but may be rejected.
I disagree. 1) There was no change in how these data are parsed in PixInsight. Versions of PixInsight before 18.104.22.1683 didn’t make use of the SITELONG and SITELAT keywords, but now they are used to acquire the geodetic location of the observer, which is necessary for ephemeris calculations performed by the astrometry engine. 2) It is not arrogant to expect that standards of data format in FITS files (here: original SBIG document FITS File Header Definitions ) are followed. Please also take a look at this conversation: PixInsight Forum
Actually the way that SITELAT and SITELONG were parsed did change in PI 22.214.171.1243, and that was the genesis of the current issue. Or to be more exact, PI changed from not parsing these values but simply passing them as unmodified strings, to parsing them. This was necessary to allow PI to use the numeric values in subsequent calculations.
There is one unambiguous format for expressing world and celestial coordinates once the coordinate system has been worked out - floating point values. The original FITS specification (by NRAO in conjunction with NASA and others, not by SBIG) seemed to recognize this. In the current FITS specification, the work of E.W. Griesen and M.R. Calabretta is included by reference to define the format for specifying world and celestial coordinates. That document, Representations of world coordinates in FITS, specifies floating point representation for the coordinate values.
The convention of using “SDD MM SS.SSS” (e.g. “+34.04.30.000”) to represent signed degrees, minutes and seconds comes from a paper published by SBIG in 2003. It is not part of the FITS standard.
In PixInsight’s defense, either the SBIG format or the floating point format is accepted for the SITELAT and SITELONG values. But PI could not reasonably be expected to accept values like “34h4m30.000s N” as a latitude in my opinion. What is the abbreviation for “North” in Katakana script? How about “South” or “East” in Kanji, or in Cyrillic?