Parsing error in PI ver. 1.8.5

[pantarei]

Hello, using Batch Preprocessing script I had this error during files integration:

"Error: Parsing OBJCTRA FITS keywords: Parsing sexagesimal expression: Parsing 64-bit floating point expression: conversion error:..."

I never had it using the previous version. I use PI for Mac.

In attach a screen shot of the process console.

Best regards

Max

[Juan Conejero]

Hi Max,

This is the expected behavior if OBJCTRA keyword values contain commas. The only valid decimal separator is the period character, so "20,5" is incorrect and "20.5" is correct.

Can you upload one of the original raw FITS files, before calibration, so I can investigate this problem further?

[pantarei]

Thanks Juan,
I would upload one of the FITS shots but since I'm not expert in this Forum I will be grateful if someone will help me for. Attached files seem to be yup to 512K and no fits are included.

Thank
Best regards

Max

[pfile]

put the file on google drive, or microsoft onedrive, or dropbox, or any other file hosting service and post a link here.

rob

[pantarei]

Sorry, I believed it was possible to upload into PI server.
Here is the link in Google Drive.

https://drive.google.com/file/d/0B2-Vvp0G9meVdWNsMldKeUVHbEE/view?usp=sharing

Many Thanks

Max

[Juan Conejero]

Hi Max,

Thanks for uploading the image. This FITS file contains the following header keywords:

OBJCTRA  '22 56 35,4'                         
OBJCTDEC '+62 40 01'                          Nominal Declination of center of image
RA       '22 56 35,4'                         
DEC      '+62 40 01'                         
CENTAZ   '328,7   '                           Nominal Azimuth of center of image in deg
CENTALT  '67,7    '                           Nominal Altitude of center of image in deg

The headers with comma characters in their numeric values are incorrect and cannot be parsed, hence the error messages. These keywords have not been generated by PixInsight, so we have no bug here. Please check the software(s) that have generated these keywords.

[pantarei]

Thanks Juan,
the software used is MaxIm DL ver, 5.24 but I never manipulated FITS header keywords before. Maybe MaxIm translates header in italian language where comma has different value respect USA.

Anyway I think this will not affect the result, I hope...

Best regards
Max

[Philippe B.]

We have exactly same error in PI as we use THE SKY X software for acquisition
There was not error message in previous version of PI.

Very strange...

 

[georg.viehoever]

I checked the FITS standard document https://fits.gsfc.nasa.gov/standard30/fits_standard30aa.pdf . Section 4.2.4 clearly states that real numbers should use the decimal point "." , not a comma "," . The issue is most likely caused by SkyX using an incorrect locale ("Italian") instead of "C" when generating those files - not uncommon for software that is being developed in non-European countries. So your best bet is probably to manually fix up your FITS files, and report the problem to the software vendor

Having said that: I would really love if PI had some way of tolerating common errors in FITS files. I absolutely agree with Juan that it is important to stick to standards, but in the end we also have to live in the real imperfect world with rather buggy software....

Georg

[Juan Conejero]

We have exactly same error in PI as we use THE SKY X software for acquisition
There was not error message in previous version of PI.

Very strange...

Previous versions of PixInsight didn't try to parse these keyword values. In version 1.8.5, the ImageIntegration tool gathers these values to generate the corresponding keywords in the integrated image.

[Juan Conejero]

Hi Georg,

Having said that: I would really love if PI had some way of tolerating common errors in FITS files. I absolutely agree with Juan that it is important to stick to standards, but in the end we also have to live in the real imperfect world with rather buggy software....

Actually, as far as I know, PixInsight is one of the most tolerant and adaptable FITS readers. We can import FITS data in virtually any numeric format, numeric range, and orientation. Other applications are quite far from providing this degree of flexibility. However, I won't write a single line of code to support nonstandard decimal separators in numeric FITS keyword values. This is just asking for too much...