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:
41⬛d8m6.720s N
*** Error: Parsing SITELONG FITS keyword: Parsing sexagesimal expression: Parsing 64-bit floating point expression: conversion error:
81⬛d19m33.600s W
*** Error: Parsing RA FITS keyword: Right ascension value out of range: ‘168.68270980429’
Pixinsight claims:
“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.
I can confirm I have the same problem. The SITELAT keyword saved by the latest SGP is an invalid format. It doesn’t impact my processing in PixInsight but would be nice to have this fixed. Thanks.
Aahh yes… I see that. I did some more investigation and yes, it is a new implementation in PixInsight, who are unwilling to change it back or correct it.
So, does that actually mean that the info is still incorrectly described in SGP?
Trying to understand it and what it means for my processing.
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 1.8.6.1473 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
Besides Ken stated a month before that he doesn’t mind conforming to the SBIG document and that he already had corrected the format of SITELONG and SITELAT in SGP (see FITS keywords incompatible with PixInsight - General - Main Sequence Software ) - however “this fix did not make it into the 3.2.0.198 beta but will be in the next”. Since then, no new SGP version was released.
Actually the way that SITELAT and SITELONG were parsed did change in PI 1.8.6.1473, 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?