Sorry for the delay, I had to put back the same setup together to test again with 1.9.1. And that did it. No more space character (see below).
Thanks for your support, Jasem.
Sébastien
Thanks for your reply Jasem.
Version is :
INDI Library: 1.8.9
Code v1.8.9-1-g4c3f1c60. Protocol 1.7.
Read More...
Hi,
I'm new here, so I apologize in advance if I'm not posting this in the right place. In such case, please let me know. Here it goes: I'm wondering if it is possible that the FITS header values for "OBJCRA" and "OBJCDEC" (see header below) are not conform to the latest NASA FITS standard (should not have a leading space). The image from which the header was extracted was taken with a Canon 650D and acquired by Astroberry/KStars/Ekos and riding on a Celestron AVX mount.
The reason I'm asking this is because it seems to give some trouble to one of my third party platesolving client which erroneously parses the coordinates as :
- parsed Ra coordinate : "00h 05m 23.33s" instead of "6h 30m 38.84s"
- parsed Dec coordinate: "-00d 02m 18.55s" instead of "4d 56m 54.41s"
I rapidly went through the latest FITS standard (fits.gsfc.nasa.gov/standard40/fits_standard40aa-le.pdf, section 4.2.1.1) and it seem that a leading string character is "significant" and hence should not be a 'space' in this context, or so I've been by the developper of the third party platesolving client. I checked with other acquisition software (NINA, MaximDL, APT, SharpCap) and they all have the same formatting without the leading "space" character for these two specific FITS keywords so would it be possible that Ekos formats those incorrectly ?
Regards,
Sebastien