DATE-OBS has unexpected meaning in SharpCapture

A place to report problems and bugs in SharpCap
Forum rules


If you have a problem or question, please check the FAQ to see if it already has an answer : https://www.sharpcap.co.uk/sharpcap-faqs

Please also read about Troubleshooting USB Issues before posting.

*** Please do not post license keys - please report any problems with licensing to 'admin' by private message ***

Please include the following details in any bug report:

* Version of SharpCap
* Camera and other hardware being user
* Operating system version
* Contents of the SharpCap log after the problem has occurred.
[If SharpCap crashes, please send the bug report when prompted instead of including the log]
Post Reply
ehea
Posts: 4
Joined: Sat Jun 01, 2019 1:27 pm

DATE-OBS has unexpected meaning in SharpCapture

#1

Post by ehea »

Hi!

As indicated by the comment inserted in the fits header (done with a ZWO ASI CMOS camera)

DATE-OBS= '2019-10-30T20:07:22.3712127' / System Clock:Frame Received

SharpCapture uses the time it receives an image for the DATE-OBS field. AFAIK this is unexpected behavior, the DATE-OBS field is intended to hold the START of the exposure, e.g. see https://www.plate-archive.org/wiki/inde ... der_format , or https://diffractionlimited.com/help/max ... itions.htm (but see [*] below)

I know that the time the frame was received is actually the only thing SharpCapture can know for sure (modulo read-out delay, transfer delay), for a CMOS camera the better approximation for DATE-OBS should be the time the frame was received minus the exposure time.

This does matter for time series photometry work, occultation timing, exo-planet transit timing etc where second-accuracy is needed, and as analysis software will interpret DATE-OBS as the start of the exposure, you run a risk of getting sub-optimal results unless you are actively (manually, script) correcting the timestamps, which is tedious.

So I would suggest that either DATE-OBS should use [time-frame-was-recived minus exposure-time] , plus a comment saying that this is actually just that, time -received minus exposure time.

What do you think?
EHEA

[*] I'll admit that strictly speaking, this is not actually non-standard.
The FITS standard states: http://archive.stsci.edu/fits/fits_stan ... 0000000000
"The value of DATE-OBS shall be assumed to refer to the start of an observation, unless another interpretation is clearly explained in the comment field".

While the comment does explain SharpCapture's meaning of DATE-OBS in a human readable form, none of the tools I know will be able to make sense of it, and they will just treat this time the way they expect it, as exposure start time. Some plate solving software I used will even re-generate the FITS header and replace the original comment from SharpCapure with it's own like:

DATE-OBS= '2019-10-30T19:17:44.133' / [ISO 8601] UTC date/time of exposure start

(w/o doing any adjustments :-( ).
User avatar
admin
Site Admin
Posts: 13177
Joined: Sat Feb 11, 2017 3:52 pm
Location: Vale of the White Horse, UK
Contact:

Re: DATE-OBS has unexpected meaning in SharpCapture

#2

Post by admin »

Hi,

Thanks for the information – I seem to see most interest in occultations and photometry from users of the QHY camera with built-in GPS function in which case the start and end of the frame are both recorded, but I can't see any good reason not to do as you suggest and subtract the exposure length from the timestamp when the frame was received to at least estimate the time when the frame was started.

Cheers, Robin
ehea
Posts: 4
Joined: Sat Jun 01, 2019 1:27 pm

Re: DATE-OBS has unexpected meaning in SharpCapture

#3

Post by ehea »

Excellent, thanks very much!

Heinz-Bernd Eggenstein
(EHEA obs code @ AAVSO)
Post Reply