MaxIm DL Pro 6.21 released 2020-01-16

[Colin Haig]

Diffraction Limited has released the new version 6.21 of Cyanogen Imaging(R) MaxIm DL Pro as of today, January 16th, 2020.
The MaxIm DL Pro 6.21 Release notes are here:
http://www.diffractionlimited.com/help/maximdl/Release_Notes.htm

In MaxIm, use the Help menu, and select Check For Updates.
It will take you to a web page to download the update.
Download then install it.

I usually recommend that people archive the installers, in case for some reason they need to reinstall a particular version.
This release has undergone an extensive beta, and customers (including some ACP users - thank you!) helped us improve the software.
Best wishes,
Colin Haig
Diffraction Limited

[Bob Denny]

Thanks for posting here Colin!!

[William Bristow]

Important !!!

There is a FITS header bug in the MaxIm DL 6.21 release that may cause corrupted image data with some camera drivers.

If you upgrade to MaxIm DL 6.21 and you rely on time stamps for photometry series derived from the FITS header entry DATE-OBS or rely on ACP's True Focal Length, True Image Centre etc, FIT's header entries then check that the DATE-OBS is correctly added to the FITS header with your choice of camera driver.

It seems that MaxIm DL 6.21 handles the DATE-OBS header entry differently for some ASCOM drivers against direct plug-in drivers.

I have lost four nights worth of photometry data this week, over three hundred images, after upgrading MaxIm DL to version 6.21 last weekend and had not noticed that the FITS header entry for DATE-OBS was corrupted, or that ACP was reporting errors with each image taken, my bad for not looking at the ACP logs until today.

I have uninstalled MaxIm DL 6.21 and reinstalled version 6.20 and have confirmed with a ACP run using simulators that the bug is not present in version 6.20.

Screen-shot images below show the FITS header and ACP Console results with simulators for MaxIm DL 6.20 and 6.21.

I was going to post this on the Diffraction Limited forum but I see another user has done that already however I think this is also worth posting here.

Bob, you might think this is worth an alert to save users from unexpected problems when they process their data after upgrading to MaxIm DL 6.21.


MaxIm DL 6.20 FITS header OK, ACP OK.


MaxIm 6_20 Fits Header ok.jpg


MaxIm DL 6.21 FITS header not ok, ACP not OK.


MaxIm 6_21 Fits header error.jpg

William.

[Dick Berg]

William, Too, too bad, but depending on how much value you put on the lost observations, using the ACP run logs you could use MaxIm to edit the FITS header record of each of the images in turn and replace the wrong value with the right value. It would be a LOT of work, but good for a cloudy night or cloudy week. Just a thought.

[William Bristow]

Thanks Dick.

I will see how much is salvageable when I get back home at the weekend.

Most of my planned ACP runs were terminated early by the ACP "Imaging error" as a result of the faulty FITS header.

I had a series of two hundred observations that were scripted directly in MaxIm, both asteroid plots and a photometry series. They went ahead as planned but there is no useful log with those and the saved date/time with the individual FITS image files on disk is only accurate to the nearest minute. I can probably use the photometry series but the asteroid plots will have to be scrapped.

Typical, three months of cloud and the first series of five consecutive clear nights mostly wasted.

Serves me right for jumping onto a new software release too quickly and not carrying out a full test before leaving the observatory for a few weeks to do it's own thing.

I shall try to not make that mistake again!

William.

[Bob Denny]

Eek! I just tested MaxIm 6.21 and the FITS headers I am getting a good Date-Obs, e.g.:

DATE-OBS = '2020-01-23T18:38:10.95' /YYYY-MM-DDThh:mm:ss observation start, UT

So this is weird! Immediately after downloading the image, it is opened in PinPoint and solved. The error message you see is from PinPoint, it can't understand the DATE-OBS info and has discarded it. This is strange, even stranger is the info that is in there, seems like some random trash from memory. My test was with the MaxIm camera control. So as I think about this, I ran a test with ACP and the camera simulator.... and now I can see the additional FITS "synonyms" that PinPoint always writes into the header:

DATE-OBS = '2020-01-23T18:50:29.080' / [ISO 8601] UTC date/time of exposure start
DATE = '23/01/20' / [old format] UTC date of exposure start
TIME-OBS = '18:50:29' / [old format] UTC time of exposure start
UT = '18:50:29' / [old format] UTC time of exposure start

I also note that the MaxIm FITS dump you posted (image) is from the temp file created by ACP, presumably because ACP was stopped in its tracks by not being able complete its process.

In any case, from what you posted it seems like this is really coming from MaxIm (two separate data points, where it appears and replacing with 6.20 clears it). Hopefully the data above will provide at least some useful info.

[Colin Haig]

If you have a reproducible test case, please report this issue on the Diffraction Limited forum.
We have no evidence of such a problem at this time, and I am not aware of any changes being made that would have caused it.
That said, if you've found something, please report it over there FIRST before firing off stuff here. If I don't check in here, DL will never know about it.

[William Bristow]

If you have a reproducible test case, please report this issue on the Diffraction Limited forum.
We have no evidence of such a problem at this time, and I am not aware of any changes being made that would have caused it.
That said, if you've found something, please report it over there FIRST before firing off stuff here. If I don't check in here, DL will never know about it.

Colin.

If you read my first post in the thread you will see that the error has been reported by another MaxIm user on the Diffraction Forum, I see no point in repeating what has already been written. In addition you have already read and replied to that post.

https://forum.diffractionlimited.com...95/#post-35908


William.

[Colin Haig]

William - we do appreciate you bringing it up, but the best place is over in the other side so that we can get to the root cause.

Here's what I know now: There is handling introduced into MaxIm 6.21 to handle cameras that have their own ability to precisely set the DATE-OBS time (eg those with a GPS-locked time stamp or other high-precision timing mechanism) that is likely involved in this.

What I'd like to have from you is what hardware and driver version and/or plug in you are using so we can try to track this down quickly. It may be that the driver for your hardware does not implement Camera.LastExposureStartTime or that we aren't handling it right, or some other possibility.

[Bob Denny]

OK, then this has been moved to the MaxIm forum. Thanks guys.