This is not possible for most cameras.
Due to work I haven’t been able to install NINA and SGP in a different device as I said. However, as Ara_jerehian said, I noticed in my NINA video from above, that that seems to be true. Specially at the end of the video, when we can see the image noise.
Once the last frame and sequence is complete… it takes a few more seconds to actually show in the screen. It seems to be the same with frame number 9, the image in the screen changes (showing frame 9) while it is already exposing number 10.
I will give it a try with longer frames, so that behavior is easier to observe
It is the ZWO ASI1600MM-Pro, I don’t know of any more specific information for the model, driver wise I updated to the latest for both the native and the ASCOM so v3.0.0.6 and v1.0.3.23 respectively. In the ASCOM driver it is set to RAW16 in both SGP and N.I.N.A.
I just ran a test, all settings were the same whether it was the native driver or the ASCOM driver 10 x 2s subs;
SGP
ZWO Camera (Native) 1m 46s
ASI Camera1 (ASCOM) 2m 10s
N.I.N.A.
ZWO Camera (Native) 34s
ASI Camera1 (ASCOM) Nothing happens when starting the sequence, N.I.N.A. can detect the camera using this driver and even shows information and settings may be altered.
When you say ‘NINA does seemingly have more native driver implementations in the code base and, in these implementations, they could have code that is more efficient than what is in the ASCOM driver.’ is it not possible to do the same in SGP?
I don’t understand what you mean by ‘SGPro simply cannot survive if all of the camera implementations are against native drivers.’
Also, I’m no expert but when you say ‘Many cameras have a notion of “hi-speed download”. SGPro does not allow high speed download for sequence images, because it comes at the cost of quality.’ The ZWO ASI1600MM-Pro is USB3 and has a 256Mb DDR3 buffer, surely does that not allow high speed downloads and safe guard the data provided that the software (drivers I imagine in this case) can handle it?
I’ve made a feature request since the Native ZWO driver downloads quicker than the ASCOM driver, but seems not their 1st priority at this moment.
In all honestly, we will not likely address any issues present with the “native” (non-ASCOM) implementation for ASI. I don’t mean to disappoint, but (explanation below)…
It certainly is, we just choose to spend our limited time on things that are not specific to gear. In this model, we defer code that deals directly with equipment to their manufacturers and SGPro gets to focus on sequencing. This is the way it should be. Spending our time on gear compatibility will drastically limit our ability to make SGPro better.
Same sentiment as above. It is a full time job to maintain gear compatibility with no standards. Solution: defer to manufacturers. In all honesty, manufacturers have the deepest level of knowledge about their own gear and, therefore, have the highest chance of developing fast, stable software designed to communicate with it.
I have no idea. This is a decision left to the manufacturer. Only they know the speed they can read off the chip without introducing overwhelming amounts of noise (read current). My point is that a lot of cameras have two distinct modes and running one camera in fast mode and the other in normal is not a valid comparison.
TL;DR
If you want a fast stable driver for ASI, please insist on it from ZWO. When using ASCOM, SGPro has 0 control over download speed… this is implemented by the ASCOM driver’s author.
A final thought… there are some inefficiencies that are belonging to SGPro just in the general process of capturing an image and completely apart from any hardware. We WILL absolutely start tearing this down (post 3.1) to see where we can be more efficient.
3 Likes
Ahhh, thanks for the clarification.
There is one more advantage if some implementation with native SDK available.
To compare with N.I.N.A in sequencing, using Native Driver you can set different gain for each filter in one target. It may helps a lot if you are rotating from LRGB to SHO according to the moonlight conditions. The same thing is in Event Settings in SGP. But you cannot control the other settings like “offset” value or some FLI Cameras’ setting.
The thing is, with Native Driver SDK implementation, capturing software controls the whole camera settings. I understand this is a critical time for releasing 3.1 and 4.0 beta, since I am also an active beta user.
As a online product owner myself, some ideas came out with actual needs day by day. And I hope it gets better and better.
Kudos SGP
Maple
The ASCOM specification supports setting gain. If the driver implements it, SGPro can use it (and set gain for your camera, per event). If the ASI ASCOM driver does not support gain, it’s because ZWO has not yet added it.
Thank you for the clarification Ken.
By this do you mean the native driver?
Been tested w/ native driver, but since the SDK is not latest, my test model of ASI533MC cannot be connected.
Maybe, but likely not… I mean the ASCOM driver. There are three layers of software when you are using ASCOM.
- The lowest layer is the one that talks directly to the camera. In order to do this, the controlling computer will use native drivers. These are low level hardware commands. When we say “Native Driver” we mean that SGPro is literally using the native driver to talk directly with the camera.
- The next layer is the standards layer for dependency inversion. This is ASCOM. ASCOM actually uses the native driver (most likely) to talk directly with the camera. It is essentially a wrapper around native drivers that has a known, published standard. SGPro has still not written one line of code in this scenario.
- The highest layer is SGPro itself (or any consumer of ASCOM). SGPro uses the ASCOM driver, which in turn, uses the native driver. Given this architecture, SGPro needs to do very little to use the camera. We say stuff like “camera, take a picture” and then the camera will do all of its stuff (ASCOM driver asks Native driver to do things) and let SGPro when the image is downloaded and ready to be consumed.
When using ASCOM (preferred), the performance of download speed (and other things) is a combination of native drivers and ASCOM drivers, but SGPro does not, and should not, have any influence over how downloads occur. Manufacturers, because of their deep level of knowledge about their specific (non-standard) camera, will have a much easier time of succeeding in this endeavor.
Hi Ken,
Since the 3.1 Stable version is about to launch. Will there be a routine to add the SDK integration routing? The most in common in .net based program is like N.I.N.A did they just upgrade the SDK and do little change in their source code as I’ve checked their git.
Currently the Native Driver for each brands are compiled altogether, so maintaining it is a pain.
Maple
We do not currently have plans to do this.