- This topic has 11 replies, 6 voices, and was last updated 1 year, 9 months ago by
.
-
Posts
-
I have recently started using an ASI 183MM Pro CMOS camera for photometry. I started off using the ZWO ASIIMG software for image capture. However on checking the times recorded in the DATE-OBS field of the FITS header, as far as I can see, these record the end time of the exposure when they should record the start. If anyone is using this software, it might be worth checking that the information in the DATE-OBS field is what they are expecting it to be. I have now switched to SIPS which seems to be fine.
I could make a strong case for either end or the mid-exposure DATE-OBS. Perhaps the strongest is for the mid-point.
In practice it doesn’t really matter as (a) you are paying attention and (b) EXPTIME or EXPOSURE is also present and correct.
The FITS “standard” is irritatingly vague about things like this and, particularly for astrometry, it is really important to know what DATE-OBS means. In most software these days it is the time that the exposure starts but sometimes it isn’t. In “good” software there is often a comment along the lines of:
DATE-OBS= ‘2021-07-26T22:03:10’ / Start of exposure
but often there isn’t and so it is always worth checking for whatever image acquisition and processing software you use.
“Good” software includes Maxim DL. It even explains the data format and specifies the time zone.
DATE-OBS= ‘2021-07-15T23:30:15’ /YYYY-MM-DDThh:mm:ss observation start, UT
EXPTIME = 30.000000000000000 /Exposure time in seconds
EXPOSURE= 30.000000000000000 /Exposure time in secondsI agree, its worth checking. I’m using AiJ for processing and as far as I can see it assumes its being given start of observation times in the DATE-OBS field coming from the capture software. I couldn’t find a way of changing that assumption in AiJ so to get the times right I had to edit the output files. If I use SIPS I don’t have to do this. For many this probably doesn’t matter much but I’m timing the minima of eclipsing binaries so if the timings of the observations are wrong, the minima will be wrong too. I can see it’s also important in astrometry.
Its also worth remembering – for astrometry certainly – that though a piece of software may say that a time given is the start, end or middle of an exposure it may not be as accurate as you would expect.
I recall some of the guys from Basingstoke society devising ingenious ways to determine how accurate the recorded time of a DSLR exposure was and finding not just the shutter/camera OS delay time, but also delays of more than a second in some commercial camera control software – which would play merry hell with NEO measurements.
The told the developers of one of the software packages, but they didn’t seem to care.
The BeSS fits standard used in the spectroscopy database specifies optionally DATE-END for the end time but I think it is rarely used and DATE-OBS (start time) and EXPTIME is normally used
“Date-Time of start of exposure ● Keyword = DATE-OBS (mandatory except if DATE-END and EXPTIME are present) ● Format: char (70 char max) ● Mandatory format: yyyy-mm-ddThh :mm:ss[.ss…] ● Example: 2006-02-25T13 :34 :43.5543
Date-Time of End of Exposure ● Keyword = DATE-END (mandatory except if DATE-OBS and EXPTIME are present) ● Format: char (70 char max) ● Mandatory format: yyyy-mm-ddThh :mm:ss[.ss…] ● Example: 2006-02-25T13 :34 :43.5543
Exposure Time ● Keyword = EXPTIME (mandatory except if DATE-OBS and DATE-END are present) ● Format: float ● Units: seconds ● Valid Range: >= 0
Nick said “The FITS “standard” is irritatingly vague about things like this ..”
According to this document, in 1997 the IAU recognised this confusion and standardised DATE-OBS as the start time
https://www.cv.nrao.edu/fits/documents/standards/year2000.txt
“4.2) Henceforth, DATE-OBS shall be assumed to refer to the start of an
observation. Other interpretations must be clearly explained in the comment field.”
Cheers
Robin
Sort of. They still allow DATE-OBS to be anything the developer likes as long as it is indicated in a comment. That means that you have to parse comments to find out what the keyword means. That is a pretty rubbish “standard” in my view. As an engineer the FITS standard is pretty much the kind of thing that I would expect a scientist to write…
“As an engineer the FITS standard is pretty much the kind of thing that I would expect a scientist to write…”
As someone who spent a career sat astride that particular fence I would have to agree !
Either way it sounds like the ZWO software is definitely non compliant though
Cheers
Robin
=for comment
Parsing comments is a non-starter for all practical purposes.
They are free text, of zero or more characters, and all you can assume in FITS is US-ASCII.
=cut
; I would be quite within my rights to create this informative FITS header:
DATE-OBS= ‘2021-07-26T22:03:10’ /Ad ultimum diem et ad tempus.
// which tells you everything you need to know.
% I am with Nick on this one.
# Sorry, I couldn’t work out how to put a Perl or bash single-line comment into the subject as well.
<!–You have to make do with Fortran, Algol68, and C.–>
Firstly, Tony, are you AJV who posted this issue to the ZWO forum in 2021-Jun-17? There doesn’t seem to be an answer from ZWO.
Becoming aware of this thread, I tested my own setup using ASIImg V1.7 (64bit) and both a ASI16200MM and a ASI174MM camera. For both cases the DATE-OBS header has the end time (or within a second or two of it) NOT the start time. This is despite the comment on the DATE-OBS entry which says “/ UTC start date of observation”.
I will also make my own posting on the ZWO forum about this. Unimpressed with ZWO on this.
- You must be logged in to reply to this topic.