×

INDI Library v2.0.6 is Released (02 Feb 2024)

Bi-monthly release with minor bug fixes and improvements

FITS Keywords

  • Posts: 35
  • Thank you received: 1

Replied by erik on topic FITS Keywords


To me, the 4.0 standard doesn't read as if it was restricted to 3 or 4 decimal places. I'm aware of the fact that 6 decimal places might be far from reality, but for instance would a INumberProperty be sufficient to state the number of decimal places that are written to the FITS header?

Concerning the actual definition of the timestamp, whether it is the starting point or somewhere in the middle of the exposure, I guess you have to know what the program wrote when making the FITS. Am I right when assuming, that INDI generally states that to be the beginning?

Well, of course, generally the longer the exposure the less relevant is the accuracy of the timestamp, but I want to image satellites and measure their orbit. Thus using exposure times of approx. 0.1 seconds. Assuming an average speed of 7 km/sec, I'd like to have the uncertainty as low as possible.

As Han pointed out 0.1 ms would be already quite good, but is yet not implemented in INDI indiccd missing one decimal place. If this collides with other programs, would it be possible to use MJD-BEG, MJD-AVG or MJD-END? I'd be happy to do the implementation and make the PR.

Same goes for the altitude, might be not too interesting when imaging stars and planets, but for me, knowing I can later read all the information I need from the FITS header makes it somewhat simpler to lay out the over all schedule of measurering satellite orbits.

Cheers
Erik
4 years 3 months ago #46772

Please Log in or Create an account to join the conversation.

  • Posts: 554
  • Thank you received: 138

Replied by Chris Rowland on topic FITS Keywords

I would avoid making this sort of change until it is neccesary.

Getting the time to microsecond precision is not available now, and may never be. Let us wait until there is a real, testable reqirement.
If this does become available it will only be so for a limited number of cameras. AIUI camera drivers export the data as a FITS file and the driver for those cameras can inplement the precision they require. If Ekos does nothing with the FITS data other than add data and save it then there may be nothing more to do.

If Ekos does update the data then this apparently simple requirement could balloon into something complex. It may need changing in multiple places. Everywhere that this is used may need to be checked to ensure that the data doesn't upset things - overflowing display boxes for example.

It would also need testing and at the momnet that's going to be tricky because there's no camera that provides data to that precision. Even using a simulator some module somewhere could silently truncate the data, maybe truncate it, then write it out with the same apparent precision.

There's more than just changing a format string.

Chris
4 years 3 months ago #46776

Please Log in or Create an account to join the conversation.

Time to create page: 0.853 seconds