SITELAT FITS keyword and Pixinsight

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.”

This is a big deal to me as it as shut my asteroid astrometry program down if I continue to use SGP.
Hope it is fixed very soon.


I saw two posts on this in the Pixinsight forum so I know others have this problem.

A temporary solution is to roll back to a previous version of Pixinsight.

BTW - you can still integrate, but not drizzle.

You can edit FITS headers in Pixinsight so I wonder if that would be a temporary workaround until SGP is changed.

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.

1 Like

I think this has been fixed… I fixed something like this recently. Didn’t make the beta though. I’ll make sure it’s fixed though.

1 Like

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.

I have this error, too. Have never seen it before until last night. Did my SGP do an update i did not know about?

No, all image acquisition software was broken by Pixinsight.

I also finally would like to see a SGP version where this issue is fixed. By now 25 days passed since Ken stated that it is corrected.

Please, release!


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 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 beta but will be in the next”. Since then, no new SGP version was released.


1 Like

Actually the way that SITELAT and SITELONG were parsed did change in PI, 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. “+”) 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?



Do we have definitive answer whether this issue has been fixed in SGP?


Here is the beta with that fix (unofficial). Will update this thread with an unofficial non-beta with that fix also:

Here is the non-beta test build. If these look OK, I’ll make formal releases: