There has been no formal request for any change to the ASCOM camera specification.
Abuse and rudeness on an unrelated site is not a request. I have described what I think is required to extend the interface on this site on a number of occasions.
I suggest that you look at that and see what you can do to help get what you think you want. That’s more likely to be effective than being abusive.
Not sure how/why my comments were perceived to be abuse. That’s not my intent. Sorry if they came across that way.
I think we are actually saying almost the same thing. I don’t think we are talking past each other. I was unfortunately trying to answer your and other questions in the same reply (apologies… this made it seem like I was unaware of your argument).
I do not dispute this in any way… My argument is, if your camera cannot set gain without offset also being set (dynamically), why would you, as a vendor, expose it and allow apps like SGPro to modify it? The fact that this happens is not a reason to disable this feature. At the most it is constructive user feedback to the vendors implementing this pattern.
Agreed. For clarity, this is more a time issue and no a difference of philosophy. When we add support for standards we like to try and do it right (or we end up here).
This will be out in the next release.
I’m fairly certain they’re using a native interface.
We’re slowly working on it. The documentation for INDI on the client side is pretty thin unless you’re writing a linux client and can directly use their library 
probably just need to reach out to them and see if they have anything else available. However I don’t think INDI is a magic bullet. INDI and ASCOM are both abstraction layers and still have to deal with device manufacturers creating drivers for their abstractions. Also INDI doesn’t seem to directly expose Gain or Offset and it’s considerably more difficult to setup for the majority of people as compared with ASCOM.
Thanks,
Jared
@Chris can I start the process to get offset added to the spec? I will do this if a non-manufacturer can do it. Please link your post when you can that talks about what is needed (the process).
I know Sam at ZWO very well maybe I could even work through him.
Thank you sir!
I’ve searched for posts where I mention ASCOM and offset and come up with some that talk about how I think this should work
and
Not sure those links have worked.
It’s almost essential to have manufacturers and application developers involved because if they are not prepared to or are unable to implement what is specified there’s little point in doing so. Jared and Ken are obviously willing but it would be really good to involve the manufacturers. This is what works. We need to get the specification right and this needs buy in by the people who will be using it.
If you, or others, can contact the manufacturers then that will help a lot. We really could do with some sort of feedback from the people who will be developing drivers that use the specification at the draft stage.
The problem with defining a specification in isolation is that we probably won’t get it right. Once they are out it’s really difficult to change them because people will use it, often without telling us, and a change will break all drivers and applications that use it.
There’s quite a lot of work in extending a specification:
And all this needs testing.
Now to manage expectations, I’ve no idea how this will go down with the other people involved in ASCOM and at present, because it has all been discussed on a separate forum, they haven’t been involved at all. It must be raised, by the people who want this, on the ASCOM-Talk forum. I will not do this. I see your, or the manufacturers, doing so as an indication of your commitment to this.
I’m sorry if this seems like a big ask but you are asking for a fair amount of unpaid work and it seems reasonable to make sure that what we do will not be wasted.
It is not unreasonable at all, Chris, to ask us to start the topic in the proper forum.
I’d be happy to do it, if no one else has. I understand that getting offset into the API could take some time. I would rather not push to get the feature rushed out, either, and I agree that manufacturers who would be developing ASCOM drivers need to be involved in the update of the specification.
Personally my primary goal on these forums was to just get SGP back to a working state for CMOS camera users. The latest releases have given SGP control over something we used to control in the driver, and for many the exact nature of that behavior has resulted in some unexpected changes. Namely, many imagers have found that, instead of their data being acquired at the higher gain setting they chose in the driver, SGP defaulted to Gain 0 and the data is not what they expected. Far removed from any changes to the ASCOM spec, I think this issue needs to be more immediately addressed.
Updating the ASCOM spec to support offset reporting and configuration can certainly wait for proper analysis and specification. 
@Chris wow thank you so much! I have reached out to Sam at ZWO to ask if he wants to help pursue this. I will lead the charge for him if he wants. Thank you so much for the insiders view on how it all happens.
I would love to have gain and offset controlled by SGP and I will work this for free if that is what happens in the end. I would ask @Ken and @Jared to weigh in on this as well also in regards to having offset be a part of the profile/control panel to be managed by SGP as gain is.
@jon.rista would probably need your help in the part of any discussion on why offest is important in relation to gain. Your explanation is always excellent.
I completely agree with Jon here. Getting SGP working for the CMOS crowd would be wonderful. Sounds like the guys are working on the fix and will include it in their next release. Fantastic! 
Also… mostly just a note to myself for later (yes I that lame that I store notes in the forum). Many have compared the gain / offset combo for CMOS to ISO. This means the ideal impl will support (somehow) both gain / offset by binning and also, conditionally by event (like ISO). No idea how to do this… doesn’t matter much right now, just don’t want to lose the thought.
“Offset” is equivalent to “Brightness” - and just like with any videocamera it is useful to shift the black point to fit the scene’s dynamic range optimally for the camera - which is only 12 bits.
In the ASI sdk, you set the offset value using the control type “ASI_BRIGHTNESS” - which is commented in the API as “offset”.
So the reason for offering both gain and offset is the same for any camera that offers gain and brightness.
I think the reason you enter both values as simple integers is that it avoids having them be calibrated. They are just relative numbers and you can’t be sure what they will actually map to as e/adu or something.
So - like many commodity cameras - the ASI and others offer some knobs to turn that let you optimize the camera for the scene. They also offer autoexposure and other things that aren’t normally in an astro ccd - but they are nonetheless useful.
As for having a fixed default offset for each gain value - my guess is that would be camera dependent - and that’s one reason it is up to the user to set appropriately. But even if it is the same across cameras - if you look at a bias histogram in a log plot, there is a long tail going to the low values - and there is no single point where you would set the black point - and offset.
My recommendation is actually to give some thought to using the native api for some popular cameras. Other apps support a mixture of native and ascom devices - and my own software, MetaGuide, does also. I find device API’s to be fairly stable and easy to work with. You just need to include the dll with the software.
But the priority now is just to get gain to behave better. I was aware of the gain 0 problem but I didn’t know the exact workaround - and I had a perfect clear night stuck with gain 0 for narrowband - which is not ideal.
Frank
This could actually be accomplished now via the Gains List in ASCOM. Essentially the client knows little about the actual settings and the driver could expose some sort of UI to control the Gains List values. Maybe something like:
List Name Gain Offset
Low Gain 75 120
High Gain 150 100
Other Gain 100 50
SGP only sees the Names and the back end values are contained in the ASCOM driver. Maybe this is something to talk to ZWO about? I can also reach out to Sam at ZWO if this seems like it would be useful.
Your Gain/Offset combos are still stored in your ASCOM driver but now a client application can get access to them in an indirect manner. You couldn’t set them individually (unless you populated every combination available) but it would give you a way to control the gain and offset indirectly.
This works on the assumption that you need a finite number of combinations of Gain/Offset. Like maybe less than 10 or so. While I have a ZWO 1600 I haven’t used it much…or any other camera for that matter in the past couple of years.
Thanks,
Jared
I think that ZWO is already pretty close to this. I requested that a UI feature for editing their preset list be added a couple months ago (as I tend to use a range of gain settings that I find optimal for different use cases, and I got tired of manually setting them all the time :P), so the ability to create a Gains list is already there. All they would need to do is expose the configured presets via ASCOM…
Good to hear. The ASCOM driver that I have installed only supports Min/Max for gain. I’ll update and see if they have something that actually uses the list.
Thanks,
Jared
Gains is not implemented in the latest ASI driver, also the Gain property returns the actual gain value not the index of the Gains array index as it should if implemented based off a Gains list. I think getting them to change to being gain list centric though is a good idea as Jared said.
Gain: 20 (what I have set currently for the gain value)
Gain Min: 0
Gain Max: 600
Gains: Not implemented error
Dim camera
Set camera = CreateObject("ASCOM.ASICamera2.Camera")
camera.Connected = True
Wscript.Echo("Gain: " & camera.Gain)
Wscript.Echo("Gain Min: " & camera.GainMin)
Wscript.Echo("Gain Max: " & camera.GainMax)
Wscript.Echo("Gains: " & camera.Gains)
' Throws not implemented error
For Each profile in camera.Gains
Wscript.Echo(profile)
Next
WScript.Echo("Press Enter to continue")
WScript.QuitThat’s kind of what I thought. Same behavior as in the older driver that I have. Sounds like they’re pretty close though based on what @jon.rista is saying. It might not be too difficult to expose that to a client.
Thanks for checking!
Jared
I am curious here, even if ZWO did add the Gains list functionality…how useful it would be if we could not actually set the Offset from within SGP. If SGP could set only the gain specified in the list items, but not the offset, then we would still have to use the ASCOM driver to configure both, as both do still need to be set together.
Or is it just that I am misunderstanding how the gains list works. If implemented, do you then simply tell the ASCOM driver to use one of the settings configured in the gains list, and the driver then sets both gain and offset?
This is what I am suggesting. As in the example above you would define “Gain/Offset Profiles” and assign them to a name that the ASCOM driver would expose in the Gains List. I’m not sure if this is a proper usage of that field or not…just a thought.
Thanks,
Jared
@jon.rista if the driver were implemented as the ASCOM ICameraV2 interface definition states for Gain and Gains, and as Jared stated, the driver would internally set the offset (from your profile item in the driver) when SGP set the Gain property then it would work great. Also Ken and Jared would not have to change anything it sounds like (which I always like, less work for them).
The definition of Gain on the ICameraV2 interface states:
“Short integer index for the current camera gain in the Gains string array.”
Right now ZWO is not returning an index to your profile in the list but the actual gain value that was last set (could be from a profile or manually entered via the main form in the driver). This goes against the spec really. Also they do not implement the Gains property, a property that should return a list of profile names, so SGP has no knowledge of the profiles setup in the driver. As you said though, ZWO is part of the way there in having the ability to maintain a list of gain\offset profiles. They just need to make their driver’s Gain property profile index centric as the ASCOM ICameraV2 interface definition states it should be and they must implement the Gains property to return the profile list (the names). They must also do as Jared suggested and when the Gain property is set (to an index of an item in your profile list) they must set both the gain and offset during this operation. That is the only way this works.
I do see a challenge in ZWO’s implementation though in that they use their profile list to “load” gain\offset values into the driver while at the same time allowing the user to then change (override) the gain\offset values in the main form of the driver UI. If they coded the driver to match the ASCOM ICameraV2 specification for Gain\Gains SGP would have no idea of these overridden values. SGP would simply be working off the profiles setup in the driver and if the user overrode the values (via the main form) then they would get overwritten. ZWO could of course have an static list item that represents the latest (last loaded or last manually set) values. This would be a way for the user to say just use what I last set in the driver manually (not loaded from a profile item). I see all of this as a small problem though.
ZWO also has to decide if the Gains list will contain profiles items (Unity, etc.) that they have in there by default or is it just the user defined profiles or is it a combination of both.
@Jared do you want me to email Sam about this also? I have no problem doing so but I feel coming from you it will carry more weight of course. Just let me know if you want others to email him also.