I think the current implementation of gain is broken and I think there is a bit of a misunderstanding on what was originally requested. I think the original request was to be able to set gain and offset on CMOS cameras on a per-event basis much like you might set ISO for a DSLR. Whereas with CCDs, gain is mostly a set-and-forget setting, there are many reasons why we might want to change gain/offset for CMOS cameras.
Unfortunately, CMOS cameras handle gain and offset differently than CCD cameras and if gain is changed, offset needs to change too. Since the ASCOM standard does not support an “offset” property, it is of no use to be able to set gain within SGP for these cameras. I think the attempt to implement the gain setting has caused a whole lot more problems than it solves - particularly since it probably doesn’t solve any problems for the reasons stated above.
I think others will agree that the best path forward is probably to revert gain settings back to the way they were and just let CMOS camera users set gain/offset in the camera driver and let SGP honor whatever those settings are. As it stands right now, SGP is very difficult to use for CMOS camera users and there is a lot of frustration over this.
I’m not trying to be critical, just sharing my thoughts. I truly appreciate that you guys try to hard to implement new features for us. I just think this is one of those rare instance where the implementation missed the mark.
I think you’re probably right here. Setting Gain is generally not useful in and of itself and the occasions where it is are likely pretty slim and dependant on the implementation inside of the driver/camera.
We’ll discuss reverting this behavior for ASCOM cameras and rethink it until Offset is also supported. I don’t think we’ll be able to support the “Gain at an event level” any time soon either.
Minimally, we’ve added a “Not Set” option which will just use the Gain that is in the ASCOM driver.
My main interest in all this was just to have the gain setting recorded in the FITS header. There is less usefulness for SGP to try to set the gain in a sequence if it can’t also set the offset. But if the user always sets specific pairs of gain/offset values in the camera - then having the gain value in the fits header would give confidence in how the camera was set during the imaging - and allow confidence in matching to bias/darks/flats. The user would write down his/her own values of offset for each gain value - and stick to that convention.
So if there is a way just to read the gain value and put it in the fits header- either as an integer or as e/adu - that would have a lot of value. I don’t see any value in setting gain in a sequence, though, if we can’t also set the offset. And I don’t see any way to set the offset for a long time - if ascom committees, standards and drivers are involved.
There are many ways zwo could help out - mainly by having a logical ramp of offset with gain so that the offset automatically changed with the gain. Having the offset user-settable is useful, though, because it lets you trade off the black point for maximum dynamic range. But given all these headaches I would just have the offset track reasonably and just below the lower tail of the bias histogram - at a given gain setting.
I absolutely agree with this. I believe gain and offset must be controllable together to be useful. However, even if gain setting in SGP goes by the wayside, I would love to see gain recorded in the fits header.
That has been in the last couple of betas. Both integer and e/adu if provided by the camera.
This is likely the case for some cameras. Unfortunately ASCOM only exposes Gain. We’ll be leaving Gain available for ASCOM cameras an adding a “Not Set” option. Use if it if makes sense…don’t if it doesn’t.
With respect to this post from @spokeshave (and other similar posts):
It’s not broken… just new to ASCOM. It’s been around for years and has nothing to do with previous user requests (more on that below).
This is not true unless you mean “set and forget” at the binning level. There are many venerable CCD manufacturers (like QSI) that recommend gain adjustment as binning changes.
We don’t dispute this. This, however, does not seem like a reason to hide the gain implementation if your camera supports it. It seems like, in the case you are referring to, that the camera manufacturer would choose not to expose gain (because of the dependency on offset).
Again, not true (unless you are referring specifically to the case you illustrated above). Many cameras do not fall into this category, but rather a category by which “offset” is important, but not super sensitive. Any value that moves gain conversions away from 0 (after error) is sufficient and this is likely fine for all binning modes. Some gibberish I wrote in another thread:
Gain is a multiplicative coefficient used to drive the CCDs preamp and offset is a linear shift away from 0 (after gain). The offset value is “just enough” to successfully shift the preamp’s multiplicative gain and the subsequent ADU conversion errors away from 0 (by rounding) and should be pretty close to the same value for all binning modes. I am honestly not sure why those values in the screen shot above are different. In a 16-bit camera, offset is expressed as a 16-bit value (0-65535). Having offset values vary by 15 or 35 ADU seems inconsequential as they both likely ensure all gain calculation have a proper amount of resolution. Offset is also not nearly as critical (unless it’s way too high)… any value that keeps all conversions “off the floor” should be sufficient. Not implying I am right, just honestly that I don’t know.
Debatable. It is an initial implementation for ASCOM… getting feedback is good. Abandoning standards, not so much (more thoughts on that below).
Not sure if others agree with this, but we state our case below (and we are providing option to honor driver settings).
@Jared and I had a formal meeting with gavels and wigs to discuss this. It seems a point of friction for some, but we have decided to leave it in SGPro. Here’s why:
The notion of gain control by binning is not new to SGPro. It has been there for years, but never before accessible by ASCOM cameras.
If your ASCOM camera exposes gain programmatically, you should be able to use SGPro to set it (yes… this is completely useful without being able to control offset alongside it).
The major point of friction seems to be that if your camera allowed for it, SGPro forced you to use it via the provided interface. So… in the decision to leave it intact, we are also allowing for ASCOM cameras to completely relinquish control to the ASCOM driver (via “Not Set”). This is also the default setting. You will need to explicitly change it if you want SGPro to control gain.
We believe in exposing and propagating the ASCOM standards. Providing access to important aspects of the ASCOM interface, even if imperfect, is the only way to encourage other vendors to actually provide support for them. This is a clear way to expose standards (as they exist) to users and provide feedback to keepers of the standards and those who implement against them (vendors). If applications like SGPro do not maintain some sense of fidelity against standards, nobody will write code against them.
FWIW, as a CMOS camera user with variable gain and offset, the ability to set (and save, to both the equipment profile and the sequence, if possible, would be preferable) to “Not Set” would be sufficient.
I think the recording of the Gain to the FITS headers is wonderful. That is something I was starting to use a command line FITS header tool to add myself, and it’s a bonus to have SGP add it for me.
I have resorted to manually putting gain and offset in my filenames. It would be nice, however, if the gain setting was exposed as a filename template variable, so we could have it added to the filename and always be correct according to the configured value (either via the SGP settings or the driver settings), rather than be manually hard coded.
Perhaps someday ASCOM will add support for exposing offset the same way, and we could get that stored on the FITS headers and in the filenames as well.
@Ken is entirely correct in his statement that QHY and ZWO both should have never exposed gain to bet set from the outside (SGP) if the offset (which is currently not defined in the ASCOM interface) needs to change as well in relation to gain. They would implement the set but the property body would do nothing.
Had they ignored a set of gain from the outside there would no issue now nor would there be the need for a “Not Set” bandaid.
@Ken can’t we get them to change this behavior? I just feel you are adding a unnecessary bandaid when this is a two second change on their end? You can’t tell me there is some software out there that needs this gain set ability (without the ability to change offset). I just feel it is wrong for SGP to have to cover for this.
@stellarskies For the sake of my own clarity here, are you suggesting that ZWO and QHY stop supporting the alteration of gain and offset in their driver? Or are you suggesting that they only allow those changes from the ASCOM configuration application for the driver itself?
SharpCap allows for the change of the offset as well. The value is called “brightness” instead of offset, but they are the same thing.
@rockstarbill I am saying programmatically changing of the gain via the ASCOM objects. The setting of gain, offset, usb speed, etc. in the driver’s UI would still be there and that is how you would manage the settings (just as we always have).
The mistake here was that they (QHY, ZWO) are allowing the consumers of their ASCOM objects (SGP, etc.) to change the gain when they should not be allowing this because the relation of offset to gain and there being no property on the ASCOM interface to expose it (allow SGP, etc. to manage it as well).
They should be in essence ignoring any request to set gain in their ASCOM objects that SGP and others use. They should only allow this after offset has been added to the ASCOM spec as well.
It is a two second change for them to disallow setting of the gain in their objects. Now that I see the entire field here this is the right path that should be pursued. @Ken and @Jared should not have to cover for this.
Disallowing the setting of gain may break other applications, like SharpCap, which they provide to their customers when they buy the camera. So, then they would be in a position to maintain a list of approved vs not approved applications for adjusting those values. While I get the essence of what you are saying, I think there are more ramifications of a change like that by ZWO and QHY than you are thinking through.
Doing the Not Set option in SGP solves the problem, and doesn’t go breaking other applications that are working just fine how they are. That seems like the prudent change.
@rockstarbill I have never used SharpCap, is it using the ASI ASCOM driver as well? If so this means there is a “Brightness” property of the ASCOM interface specification that ZWO is using for offset and that is not really right either. They are using another property meant for brightness for offset. I know you understand brightness is offset but they should be two seperate properties on the ASCOM interface spec, one for brightness and one for offset. I am talking at the code level here so I hope I making sense.
I am not disagreeing with you about what is right or wrong from a coding perspective and standards perspective. That is a different discussion entirely though than a knee jerk change by ZWO and QHY that could potentially break working applications. The right change here is the Not Set option. That gets users of SGP working correctly again, without needing to go into the Control Panel constantly to reset their gain, and keeps other applications working fine as well.
I am not sure what SharpCap does, in terms of interfacing with the camera. It might use the ASCOM driver objects or it might be adjusting the Windows Registry directly to change those values. Only they could answer that.
I work in software, so yes what you said made perfect sense.
@rockstarbill that is why we have a forum so others can read what I am saying. I did not know of SharpCap and how it interacts with the ASI’s so thank you for educating me.
My real point here is I see where the real issue lies now. Messy driver situation that is really a result of new technology and a slow process to update ASCOM specs.
Software makers being beholden to ASCOM’s molasses rate of change doesn’t make a ton of sense either - to play the devils advocate. If variable rate cameras are hitting the market and the ASCOM folks can’t move along fast enough to keep up with the market changes, why should the manufacturers delay? I don’t think they should. Standards are one thing, but draconian application and adherence to process for the sake of process is a waste, IMHO. It is stuff like this that makes INDI look better and better everyday. SGP on INDI would be awesome. Jared and Ken could get out of caring about drivers, and care more about an incredible client experience. I know this is getting off topic though so I will digress.
@rockstarbill maybe it is not a slow process to update the ASCOM specs, maybe there are a lot of hoops to jump through? @Chris would know more than I do about that. I agree that manufacturers can’t wait for the committee to update the standard. Pushing forward though can sometimes put Ken and Jared in a tough spot like we are in now.
The “Not Set” option will deliver us from this temporary setback but as a developer myself I wish the solution were cleaner (and less of a burden on Ken and Jared) than this. It is what it is though.
A single author publishes a draft interface specification. Ideally, this will be derived from an interface already in use and not designed in a vacuum.
Discuss the proposal on ASCOM-Talk until an interface agreement can be reached.
Implement a simulator which has all of the properties and methods of the proposed interface (a reference implementation). Ideally this would be done by someone other than the author. Make the simulator available to anyone who wishes to play with it.
Refine the specification and simulator as dictated by experience, again reaching an interface agreement brokered by the author. Discussion is closed at this point.
The author posts a poll on ASCOM-Talk, giving the community several weeks to vote yes or no. Further suggestions and other feedback will be rejected at this point.
If the majority votes yes, the specification is considered "adopted " and the author is responsible for writing the final standard document. If not, either go back to step 4 or drop the spec entirely and possibly start over.
At the end of the day, getting the Not Set capability into SGP will be great. Solving the long term problem of setting gain/offset seems to be a challenge. I am sure some folks will want offset to be changed - yet invisible to the user (and not handed to them for direct control) whereas other folks will want both values exposed programmatically for any use. Both of these have their pluses and minuses.
That’s exactly what I mean. With a CCD camera, once you set the gain (for all bin modes) you are not likely to need to change it ever again because there is not real advantage to it. With a CMOS camera, on the other hand, you may wish to select a different gain for multiple targets or events within a sequence. You may want to select low gain for long-exposure narrowband frames to prevent blowing out stars, but a high gain for short exposure Lum frames of a bright target.
I think we are talking past each other. I am speaking specifically about the new CMOS cameras (see thread title) not CCDs. Jon.Rista gave a good explanation of why offset must change with gain in CMOS cameras in another thread. Binning is irrelevant for these cameras since it is software binning and has no advantage over downsampling in post. On the other hand, as I mentioned above there could be great advantages to setting a different gain for different targets or events, but only if the offset could be changed correspondingly.
I don’t disagree. I think supporting every capability the ASCOM standards offers is important (more on that below). However, the current implementation of gain in SGP is causing a lot of problems for a lot of users. A fix is desperately needed fairly soon. I was simply offering a very simple fix that would restore usability for CMOS camera users. It sounds like the “Not Set” fix will be just as effective and serve both purposes.
I fully agree with this and is one of the reasons I asked for the exposure of the TempComp property to the user in another thread. It would actually make internal temperature compensation useful to the user and would encourage focus driver manufacturers to more fully implement the property (few do).
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.
