I am just trying to get my head around autoflats so maybe missing something but does this take Camera Mode into account, I can’t see it anywhere, it only seems to allow gain and offset?
Can we have Camera Mode added to the fits header please. I sometimes use the same Gain and offset with different modes and with it not being recorded in the header it can be a PITA. I went back to process some old data and wanted to run some new calibration frames but couldn’t work out what mode I had used at the time. it would have been useful to just look it up.
Currently, it does not, but this is indeed the best place to ask for it.
This has been around for quite a while now. If your camera reports it, it is inserted into the headers as both READMODE (in the 4.4 beta) and READOUTM (in current 4.3 release). Maybe it’s not present for non-light? I’ll verify.
The summary is this: The QHY drivers do not report the camera’s readout mode correctly and, because of this, SGPro reports incorrect info in the headers.
Thanks Ken. My head exploded before I got to the bottom of that but I hope QHY/ASCOM can work it out. I understand why you want to stick with the ASCOM driver, I worked in systems development for 40 years, but the native driver seems so much better in this case and my testing of NINA (native) vs SGP(ASCOM) showed it to be much faster on downloads.
We actually had native drivers to start, but retired them in favor of ASCOM. An outfit our size simply cannot afford to commit to native driver support for all the gear we support. That said, we may be willing to (begrudgingly) support QHY and ASI natively because of their popularity. Certainly not committing to that here at this point, just noting that it’s not off the table.
If ever you decided to go down that road, that would definitely bring me back to SG, as my QHY294M as a real advantage in using different modes, at least when doing different target types as is typical in this season.
I completely understand. I hesitate to say this on an open forum but I am considering moving to NINA because of this issue, and I really don’t want to because I really like SGP and it will be a painful process. However, the benefit of having the Mode is important to me and perhaps even more important is the native driver does downloads on my setup in around 2s compared to 7s-8s using ASCOM. That’s quite a few extra subs over a year, quicker focusing, and it also allows me to take shorter subs.
A little background:
I take 40 - 50 fifteen-minute exposure with each of LRGBHa and sometimes SII and OIII, so it takes quite a while to get all the pictures for a given target. I usually have 4 or more targets in any sequence, and almost never finish a target before it’s no longer up at night. I currently have 5 active targets and 5 more I will work on when they are back up.
When a target is no longer in the sky, I do a “Save Sequence As” and give the new file the name of the no-longer-in-the-sky-target. In that sequence I delete all the other targets, then open the original sequence and delete the no-longer-in-the-sky-target.
When that target is back in the sky, I open its sequence file, do a screenshot of its RA, Dec, angle, and event info. I then open the sequence file I’m currently using and import the other sequence file. Because importing a sequence doesn’t import the event info I manually enter it from the screenshot.
Request 1:
Have the “import a sequence” action import everything including whether or not the “Slew to and center” check box is checked. I want those targets to be IDENTICAL to what’s in the imported sequence.
Request 2:
Not sure exactly what to ask for, but I’d like something to make the process of “archiving” and “un-archiving” targets easier. Having to do a “Save Sequence As” then delete some targets then delete the saved target then import 6 months later is a hassle.
One possibility would be to allow each target’s info to be in a separate file, and a sequence would logically be a list of target files. “Archiving” a target would simply be removing its file name from a sequence, and importing it back in would simply be adding the file name to the sequence.
There are lot of things to do on SkyFlats taken by AutoFlats.
Bugs/feature requests:
Autoflats scheduler when showing before and after previews (via right-down corner), it not correctly updates the screen (time of start and end when it should run) or updates it only after a few seconds
Autoflats scheduler should not run in times when it was not scheduled to run. It should behave like it is not enabled and not ask every time during the night if it should run. This of course only in case if the light source is Sky.
Autoflats sequence should behave like regular sequence target. In case if light source is Sky, it should open the dome->sync the mount with dome, connect equipment and begin to take flats
In case of SkyFlats, in case of minimum exposure time detected in the evening or maximum eposure time detected in the morning it should not abort the flats sequence, but it should wait for 60 sec. and try again, because the sky will be dimmer/brighter in a while.
The autoflats sort order “Narrowband toward light” is great, but it would be better if default order will be “Ha, SII, OIII, R, G, B, L” in the evening and reverse order at morning. Today it is not reversed and is changed to this “R, G, B, L, Ha, SII, OIII”. This is wrong order, because the exposure times are not in “right” order to be ± equal to each filter in the changing sky light conditions.