SGP and native ZWO ASI support

The issue is that the ASCOM standard for cameras does not expose the OFFSET value for SGP to set. Until the ASCOM standard changes, this will not be available.

Shawn, that’s exactly my point.

Since SGP already supports SBIG and QSI natively why not ZWO and implement offset using the API ?

1 Like

Can you shed some light for a newbie?

What is the offset setting? I see it and dunno. I realize the gain is like ISO.
also why are you wanting to use 200/50 short subs for HA (because they look more grainy?)
vs LOWER gain for RGB and longer subs?
I’m new to the filter thing and curious about the reason to change gain for various filters. (other than we’d need higher game for SHO due to longer exposures to shorten them).
But you’re suggesting the opposite.

Offset is a new setting which aims to avoid situations where due to the imaging settings you would have negative ADU values i.e. clipping on the left side of the histogram. Offset allows you to “offset” the left (darks) side of the histogram into positive values. This setting is mostly dependent on the gain value used.

In a nutshells transforms this:

Into this:

More details here.

Because QSI has built-in filter wheel and share USB port with the camera, there is no ASCOM standard to support this. What QSI did was wrote a modified ASCOM driver to support BOTH camera and filter wheel that shares the same USB port. I don’t believe it was much work for SGP because QSI provided SDK to SGP and I would expect more or less plug-and-play.

I am not familiar with SBIG cameras but I expect the optional filter wheel connects to SBIG camera and also share the same USB port with the camera, therefore SBIG also provided their SDK to SGP.


There’s nothing to stop a developer implementing separate Camera and Filter wheel drivers using ASCOM. ASCOM provides the LocalServer as a way to do this. We provide documentation and templates to help with this.

Don’t go offtopic, this topic is about using the native SDK from ZWO and implement direct API access in SGP replacing ASCOM. Why ? Because this seems to be the only way to expose the Offset option so we (ZWO users) can fully use our cameras in SGP’s sequencer.

Stop speaking about filter wheels and other nonsense, thanks.

There’s no need to be rude.

I was responding to @topboxman who incorrectly said that you couldn’t have combined camera and filterwheel drivers with ASCOM drivers. You can.

As for offset, the last time this was raised I said that the place to request this was on the ASCOM forum. Several people said they would do so, but didn’t. Not one single post about it. No requests at all, not from users, nor from camera manufacturers.

None the less some senior members thought about this including consulting camera manufacturers and were assured that there is no need to add this to the ASCOM interface.

So we didn’t. We aren’t going to go through the considerable work required to implement something that’s not wanted.

The problem with adjusting offset is that doing so will invalidate calibration frames. In particular if people are adjusting offset to reduce sky glow then it isn’t possible to correct for dark frames because the black level will be less than zero.

You may need to adjust offset as a function of gain to ensure that the dark ADC value is just above zero but there’s no need to have that controllable by the application. Put it in the driver or the camera.

It was not my intention to be rude, I’m not a native speaker so I apologize if the sentence sounded rude.

My point was just not to go offtopic, some cameras have Sensor+Filterwheel in a combo but that’s not the reason behind SGP integrating them by SDK and shall not be used as an argument against SGP integrating ZWO’s SDK.

Offset messes calibration frames in the same way as changing gain. People know what gain is and how to work with it, people must learn what offset is and used it correctly, i.e. calibrate the black clipping for a specific gain.

Offset value is a setting that will, potentially, change with any Gain change. If I use variable Gain on a sequence on SGP the offset will be out because I cannot set it automatically. Offset should be an adjustable property for a sensor in the same way Gain is. Of course I can always go to the driver and change it but the point here is automation.

Offset may be needed but there should be a constant relationship between gain and offset - that which will cause the black point to be set correctly. That functionality should be in the camera or the camera driver. There’s no need to expose it to the user.

Sorry to be off topic here. I apologize for giving incorrect statement about QSI not have ASCOM driver. I found this from another post by Ken:


Thanks for that Peter, I’d missed that. We aren’t dealing with an ASCOM driver at all. I’m very unimpressed by QHY.

This is an example from TimN at Cloudy Nights:

Optimal Exposure:
Median ADU shown in SGP -
Gain 0 Offset 10: 400 ADU
Gain 75 Offset 12: 550 ADU
Gain 139 Offset 21: 850 ADU
Gain 200 Offset 50: 1690 ADU
Gain 300 Offset 50 : 2650 ADU

You can clearly see that the relationship between Gain and Offset is not linear.

As of now, there is no intent to offer native support for any new cameras. The current native support only exists because there were 2 popular camera lines that did not support ASCOM (SBIG and FLI). That said, SGPro will happily support any changes or additions to the ASCOM implementation.

I think the only way to get Offset control is to see if we can get ZWO and QHY to put their backing behind having it added to the ASCOM spec. That seems to be the only way the ASCOM developer(s?) would be willing to invest the time, if there is manufacturer backing. I think it is indeed a critical factor now for CMOS cameras, given they have both adjustable gain and offset.

That said, in the mean time, it should be possible to find a “happy medium” offset that would work for all gain settings, if you really needed it. Personally, because of some strange gain/banding issues at very low gain settings, I don’t really use my ASI1600 below Gain 76. I did some evaluation of a bunch of additional gain settings, and found that 76 gives an FWC o ~8192e- with read noise of ~2e- and gain of ~2e-/ADU, which delivers exactly 12 stops of DR. Combined with the 12-bit ADC units, this is basically the sweet spot for the camera. I used an offset of 15, however I think it would be just fine to use an offset of 20 or 30. At an offset of 30, I think you would be good to image from Gain 76 up through Gain 200, which is quite a range (gain goes from ~2e-/ADU to ~0.5e-/ADU).

The difference in read noise from Gain 200 to 300 is about 0.15e-…not really enough to fuss about. So I think you could actually have quite a bit of success with just configurable gain in the sequence editor, by using a fixed offset of 30 ADU. Set it once in the driver, and forget it. It sounded like the SGP devs are certainly open to adding gain as a first class option in the sequence editor (I started a thread bout that a couple months back and it seemed well received). I hope it’s still on their radar, too! I am hoping to get into some more LRGB as fall rolls in later this year, and it would be really awesome to be able to set gain for each filter…use a low gain for L, bump it up a couple notches for RGB and stick with a consistent exposure for all filters.

Yes that’s it Jon. There’s no point in changing the specification if the manufacturers aren’t going to use what we implement. The last change was made as a result of a group of manufacturers getting together at an imaging conference and agreeing a change.

The need for offset control isn’t universal, even with CMOS cameras. My Altair camera doesn’t have it.

AIUI an alternative to giving the user control over offset would be to set it in the camera or driver as a function of gain.

This is the answer from SAM on the official ZWO forum:

Sam and I had some conversations about using the current ascom standard to gain access to gain and offset pairs that could be setup in the ASCOM driver. I’m not sure where they left with this but he seemed agreeable to it. I’ll touch base again.

Unfortunately native support is not free and it is an ongoing cost for us when manufacturers change drivers or camera models. So we generally tend to avoid it where possible and push that back to the manufacturer (via their implementation and support of an ascom driver)


1 Like

Jon - thank you. This was most helpful and a logical approach to the problem. Appreciate your input.

In the ASI sdk, offset is referred to as “brightness” - which is another name for what it is doing. The sdk also allows changing gamma - and you can do that from sharpcap. Do people also want an option in ascom - and in sgp - and in every sequence - to control gamma? Do they want darks and flats and bias all with different gain, offset, and gamma?

I have several ccd’s and many video cameras - and the ccd’s don’t even allow changing gain - let alone the other things. That’s fine because the bias value isn’t very large and they are 16 bit cameras. But with 14-bit there is a bit less room and if the bias or offset or brightness is really high then you lose dynamic range. And if it’s too low then you clip and can’t calibrate well.

Sam’s response is to use a fixed and high value of offset to keep things linear and keep things simple. The thing is - people can do that already - just be setting the offset high and keeping it there. They can change gain and have good control - and the only thing they really lose is a small amount of dynamic range.

As a compromise it seems reasonable to have the ascom driver have some proportional setting that increases offset as gain increases - and does it in a very fixed and repeatable way. Then users don’t even need to know what the offset value is. It basically puts it in an automatic mode that is slaved to the gain value. No changes to ascom or sgp - but the ascom interface to the camera would need a special setting or something.

Otherwise - there is an awful lot of complexity all over the place - including in the imager’s own sets of bias, darks, flats - let alone the ascom spec and the sgp UI.