When NINA plate solves internally, it passes the original, unstretched image to the configured solver. The API call in NINA that APPM uses to get an image actuates the same logic that is used by the sequencer to grab a generic light frame. So, no hidden magic is going on there, either. NINA takes the requested image using the supplied parameters, plops it on disk as an unadulterated FITS file, and tells APPM where to find it in its API response.
toggle quoted messageShow quoted text
Right now, NINA's API supports getting only light frames as doing darks or biases were beyond the original scope of the API's implementation and needs, so it's quite likely that 2 light frames are being made and one is being subtracted from the other. Even if fetching darks were supported, DSLRs don't have the kind of mechanical shutter in, and logic in which to control them, that some astrocams have that allows them to do "real" darks. Canons do have a "Long exposure noise reduction" feature where the camera does its own dark subtraction exposure, where a second dark frame is created after the light frame with the mirror down and curtain closed and is subtracted internally, but this is all internally managed in the camera and cannot be managed by external software, at least in the models that I'm familiar with.
So, in short, don't configure auto dark subtraction with a DSLR. They're not able to do that kind of thing (create on-demand darks) anyway. An alternative for this would be the ability to specify a master dark file for APPM to use. This kind of stuff isn't usually needed with today's CMOS sensors as plate solve exposures are only a few seconds long (unless you have a horrific focal ratio and/or small FOV) but yeah could be useful for older cameras or noisy DLSRs that are roasting in the summer heat.
On Sep 7, 2021, at 03:14, Seb@stro <email@example.com> wrote:
Just following up on this as it may be of interest to others with a similar problem as mine...
Here goes the story.
Since APPC 1.9 has been out in the wild, I have not had many clear nights to test APPM w/NINA+ASTAP, except one, a few days ago. You guessed it, when doing a run not a single frame solved successfully (sigh). Even under one of the clearest night of the month... But curiously, when I hit the Platesolve and Recal button in APPM (without moving the mount from the last unsolved modeling point), solving was successful !?! Tracking was ON. Settings unchanged. So I decided to take snapshots within NINA with same exposure time and gain and sure enough, solving would also occur almost instantly (couple of seconds at most, also using ASTAP). Went on and compared both APPM and NINA platesolving configuration. Comparable settings were a match. Scratched my head... Then I thought, something must be happening when APPM "fetches" the image from NINA. IIRC, NINA also applies a pre-processing stretch to help with platesolving internally. But does APPM does it too, I asked myself ? If so, is it that each frame is over-stretched (as in stretched by NINA + stretched by APPM) or even not stretched enough - or underexposed - to platesolve)? But then, why am I seemingly the only one out there with this issue? Decided to check the unsolved frames saved in APPM's folder. They were definitely unusual (and unusable), almost black and white and VERY VERY noisy (hint). Weird... And not surprising they were not solved. Then I realized some files were named with Image-APPM-date-time-coord filenames, other with "SyncNow" prefix and some were with a "Dark" prefix (should have rang a bell)... Figured the firsts were those from the run (always failing), the seconds were those when from the "PlateSolve and ReCal" button and the latter, of course, dark frames. I recalled having set that option (dark substract) somewhere but couldn't find it off the top of my head and didn't realize it *might* have explained pretty much what I was experiencing... As time was flying by, I decided to let APPM alone and just went on with my imaging plan, thinking that I would take another look at all this with a fresh mind another day... (Which happens to be today!)
So a question (or a bug fix ? or maybe a feature request, if possible) for Ray / Dale which I hope will officially put an end to my solving issues w/APPM+ASTAP :
Is a Canon DSLR a supported "NINA camera" with the "Auto Dark Substract" option set in APPM?
My guess is it's not right now because in my case, the dark frames I talked about above are shinny little stars on a velvet background (just checked)... :D So, supposedly, the reason ASTAP is always failing when invoked by APPM during a run is because it's trying to solve a "noise frame" (light frame substracted from a light frame) ! 8-)
Anyway, I unchecked the option and will give another try at this on the next clear night.
[To be continued...]
BTW, thanks Ray for the latest release of APCC 220.127.116.11a. Certainly appreciate how quick it was fixing those bugs.