Error in ASIIMG FITS header

Home Forums Variable Stars Error in ASIIMG FITS header

Viewing 11 posts - 1 through 11 (of 11 total)
  • Author
    Posts
  • #575015
    Tony Vale
    Participant

    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. 

    #584535
    Paul Leyland
    Participant

    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.

    #584537
    Nick James
    Participant

    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.

    #584538
    Paul Leyland
    Participant

    “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 seconds

    #584539
    Tony Vale
    Participant

    I 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.

    #584540
    Grant Privett
    Participant

    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.

    #584541
    Robin Leadbeater
    Participant

    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

    #584542
    Robin Leadbeater
    Participant

    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

    #584543
    Nick James
    Participant

    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…

    #584544
    Robin Leadbeater
    Participant

    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

    #584545
    Paul Leyland
    Participant

    =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.–>

Viewing 11 posts - 1 through 11 (of 11 total)
  • You must be logged in to reply to this topic.