I am using MaxIm DL (LT version, updated to 7.1.1, DLAPI 3.0.1.0, ie current today), with an SBIG Aluma AC2020bsi camera. MaxIm is writing the END TIME of the exposure to the DATE-OBS FITS header word.
The software documentation says it is writing mid time of the exposure, but it is not.
If your use of the FITS file assumes DATE-OBS contains mid time, or start time (which is what I am used to, with other software), the times of your photometry are in error. For my exposure lengths, typically 2 to12 minutes, this amount of error is greater than the astrophysical phenomena I am looking for in eclipsing binary observations for determining time of minima. I.e. this is a significant error.
I reported this to Diffraction Ltd in Oct 2023, and recently re-posted to their support forum. This MIGHT only affect this camera model, I do not know. I don’t know how long the problem has existed, my first use of this camera and software was Nov 2022.
Addendum/correction: actually, the first image after a powerup of the camera, the DATE-OBS field in the FITS header gets the start time of the exposure, subsequent exposures get the end time.
In my Maxim V7 image, the date-obs header reports it is providing the image start time, which is what I ‘recall?’ setting it up for in my first use of a much earlier version.
Did you set it up differently? Can you change it? My photometry software uses this header start time and 1/2 exposure to calculate mid-time.
To my knowledge, I cannot change it. I did not “set it up”. I’d prefer start time, as all my processing and analysis scripts (that I’ve been using for 25 years!) correct from start time to mid time. But the HUGE issue is the doc says it is mid time!
When I look at the FITS header, it doesn’t say anything about what the DATE-OBS header is (start, mid, or end). The DATE-OBS record just gives the numbers and describes the format as “YYYY-MM-DDThh:mm:ss…” etc. I’d send a screen capture, or attach a file, but can’t see a way to do so here.
I just did a search of the 823 page doc for the string “DATE-OBS”. One instance says this header word records mid-time, and the second instance pertains to interaction with ASCOM (which I do not use). The doc says the mid-time “feature” was implemented in version 6.24, so perhaps it was start time before then?
The doc implies mid-time is best when StackPro is used for stacking up to 16 sub-images in CMOS cameras. I am using a CMOS camera, but for the tests I was NOT using StackPro. (And I sure don’t want it to use a different time convention for one-shot and StackPro images!!!)
NOTE, I am only testing this on the AC2020bsi camera. “Old” SBIG cameras, e.g. the ST-8 (of which I have several, but do not use MaxIm with them), use a different driver, and I don’t think MaxIm has this problem with those cameras.
After years of using Maxim, I find it hard to believe that such an image time issue would not have been identified. However, I must admit that I’m not sure that I have actually carefully compared my Date-Obs fits header ‘start time’ to my NTP adjusted computer time for my typical 60 sec exposures. I’m quite sure I would have noticed a multi-minute time error but perhaps not a 30 sec difference? I run my images in an automated fashion so I’m not usually awake/watching to see what my clock indicates when each image actually starts!
I WILL check this issue on my next clear night. It should be simple to watch and record WHEN one or two images start on my NTP computer clock and confirm what the fits header reports. BTW, my date-obs header in Maxim does include a ‘definition’ statement as follows: DATE-OBS = ‘2024-11-17T09:21:43.820’ / [ISO 8601] UTC date/time of exposure start.
I assume that is what you have done to identify this discrepancy?
Ken
PS: Would be good to get a few other observers to check as well.
Ken, I agree with you 100%. I used MaxIm back around 2000, and would have checked this carefully. Yes, you are correct: I am comparing what is in the FITS header to what the computer system clock was reading at start time of exposure.
Here’s my update as of today:
MaxIm doc says that starting in version 6.24, they are writing mid-time to DATE-OBS. It looks like this only applies to cameras using the “DL Imaging” camera driver, i.e. newer cameras. I haven’t seen anything explicit re older cameras, but the doc is huge and I may not have found it. Just searching on “DATE-OBS” didn’t yield anything about this aspect.
for an old camera (e.g. ST-8XME, which uses the “SBIG Universal” driver), my DATE-OBS header records contain start time of the exposure
for a “new” camera, (AC2020bsi, which uses “DL Imaging” driver), my DATE-OBS header records START time for the first exposure since powerup, and END time for all subsequent exposures. Never MID time as per the doc.
my DATE-OBS records in the FITS file does not look like yours. Here’s an example from an image taken yesterday:
DATE-OBS= ‘2024-11-16T01:26:00.58’ /YYYY-MM-DDThh:mm:ss observation, UT
I see similar format/content for DATE-OBS records from both the old ST-8 and the newer AC2020. Note that I do not use ASCOM – are you acquiring images through ASCOM? Might that be a factor? I speculate about this because the MaxIm doc says that if using ASCOM, you select that driver at the place where I select one of the two camera drivers, and there are some ASCOM settings re DATE-OBS.
I posted this to the Diffr. Ltd support forum over a year ago. It is not fixed as of this week. Eric Dose posted there (Oct 2023) that his AC4040 did not do this – it stores mid-time. Diffr. Ltd confirmed that and said it affected the 2020 and not the 4040. They didn’t say, and I don’t know anything about other “current” cameras.
SUMMARY: When I use use MaxIm DL with different cameras, some using the “legacy” “SBIG Universal” driver, and some using the new “DL Imaging” driver, it writes the DATE-OBS record using different conventions. For old cameras (ST-8XME) it writes start time; an AC4040 camera would write mid-time; my AC2020 writes end-time (except start time on first image). Other models, I don’t know.
It would be very helpful if anyone else using an AC2020bsi would test and confirm!
Read your comments a few times. I also have an SBIG STL6303 (using SBIG Universal) and an Aluma3200 (using DL Imaging). They both give the Fits Header (Date-Obs) with the start time statement that I showed previously. I am using Maxim DL Pro V6 (6.50).
One thing I did just confirm is that I have always had ‘Use IRAF convention…’ checked under Settings>FITS Header. Could this be a key difference? Do you have this checked?
I also use CCDAutoPilot V4 as my imaging system umbrella. It uses Maxim but I do not see any setting for header image time?
Hi Ken, thanks for your comments, and support in this!
I’m running on MaxIm DL (LT) 7.1.1. But I first discovered these problems in 6.3, and then 6.40. I upgraded to 7 in hopes they would be fixed.
I just tested again, on the AC2020bsi, before and after setting the FITS header setting to “use IRAF convention”. It made no difference to the DATE-OBS times that were recorded (start time on first image taken, end time on subsequent images taken), and also did not change the format of the DATE-OBS record in the FITS header (it does not specify start, mid, or end).
As expected, setting that switch to “use IRAF convention” did change the IMAGETYP record, but that has nothing to do with time.
Yep, John Smith (CCDAP programmer) retired this past fall.
I copied following from Maxim help document:
<<* DATE-OBS – date of observation in the ISO standard 8601 format (Y2K compliant FITS): CCYY-MM-DDThh:mm:ss.sss. The Universal time at the start of the exposure is used. Note: the alternate format using DATE-OBS and TIME-OBS is not written, but MaxIm DL will correctly interpret it when read. The time is written to 10 ms resolution. The default behavior is to report the start of observation time, but individual camera drivers can change this. As of Version 6.24 the DL Imaging driver sets the time to exposure midpoint.>>
As I mentioned previously, I still get Date-Obs start time as indicated previously. I definitely need to conduct a test to confirm!