The new CMOS cameras, such as the QHY ColdMOS (e.g. QHY163M) and ZWO CMOS (e.g. ASI1600MM-C) are more like DSLRs in having variable gain. I expect most users of these cameras would find it more useful to be able to set the gain when they set up their imaging sequences rather than binning. As is, they are treated like CCDs and the available field in the sequencing windows is binning; gain has to be set in the camera setup dialog. I would find it more useful to be able to set gain in the sequencing window rather than binning (they donāt do true hardware binning anyway). Is this feasible? Do other users agree?
ā¦Keith
1 Like
I agree, but we would need to be able to set gain and offset. Gain alone would not be particularly useful, I think. Great suggestion. It is something I could have used in a sequence just last night.
Tim
Good point Tim.
I agree that this is important - but Iām not sure about how these things are supported from ASCOM. So until they are available via ASCOM - and then supported by the camera driver - I donāt think sgp can or would be able to do anything.
I would also add even the USB usage setting as something to put in the fits header.
My guess is that cmos cameras will be more and more popular - and they will also have special settings that will be important to record. I donāt know how this stuff will pan out - but Iām already having trouble mapping darks and bias to different sessions. I just need to keep notes and name files appropriately.
Oh - and being able to use different settings for different targets in one session would be useful. I am mainly using high gain for faint things and short exposures - or lower gain for brighter things when I want to avoid saturating stars.
But I realize this may be a ways off from being implementable.
Frank
Gain is supported in the ASCOM specification. Itās up to SGP and the camera hardware and driver to implement it.
The ASCOM specifications are published and anyone can read them.
Gain is already needed for some ccdās so no surprise there. But are offset and USB usage?
As Tim says - gain alone isnāt really adequate.
Thatās what I meant by support of āthese things.ā
Frank
Implementing gain should be relatively simple since it is an ASCOM property. Offset and USB usage arenāt, though Iām not sure I see the need for USB usage. Why would one want to change that in a sequence?
Anyway, it is a moot point. With no ASCOM property for offset, I doubt they would be interested, nor would I encourage Ken and Jared to implement camera-specific features.
Having said that, we could lobby ASCOM to add offset to the standard. Both ZWO and QHY (the primary CMOS camera suppliers) are active in driver development and if the property were added to the standard, I suspect that both companies would be willing to update their drivers.
Tim
I agree we should star lobbying for adding Offset to the ASCOM standard. USB Traffic is more of a equipment constraint so Iām not sure I see the utility of changing that in a sequence. I think CMOS cameras with variable gain and offset are here to stay so it would be great to be able to control the full capability of the cameras in the ASCOM driver.
ā¦Keith
A bright object or lrgb might use low gain for high dynamic range and a faint object or narrowband or short exposure lucky imaging might want high gain.
And any time you change the gain you really need to change the offset.
So u could have different types of objects in one sequence.
I mainly would like such info in the fits header so I donāt have to keep notes on it.
My main point is that I agree it would be good to set and record these parameters. But I can see it would be hard to do it.
Frank
By all means do so. But we have found that adding properties because users think they would be nice has not been successful. What we have found to work is at the request of device manufacturers and/or application developers. They know what they need and what they are prepared to implement. The last Camera upgrade came like this, a group of camera manufacturers and application developers got together at AIS a few years ago.
As far as I know neither of these suppliers are at all involved in ASCOM, by which I mean that the driver authors donāt have any sort of presence on the ASCOM-Talk forum. I may be wrong, they could be there incognito.
In my opinion you will be better off persuading them that you need this. We will be happy to work with them to extend the specification.
We need some sort of buy in from hardware people and application developers that they will use new functionality, not least in order to implement what they really need.
There is something that is available now in the ASCOM specification - the Action method and SupportedActions property. An Action could be added called āOffsetā with a parameter of the offset value. It would return the current offset.
All implementers could implement this now and if they all agree to use the same Action name it would work with no changes to the ASCOM specification. If it proves to be useful it could be added to the specification.
The thing that worries me is that the point of ASCOM is to define a common standard for all devices of a particular type. Having a multitude of different properties that have to be used differently depending on the type of device thatās being used rather defeats the purpose of a standard.
Chris
Chris:
I agree that trying to shoehorn the āActionā method into something it isnāt is not a good practice. However, what about the ReadoutMode and ReadoutModes properties? The ASCOM documentation doesnāt go into detail about what the purpose of these properties other than ReadoutModes is a list of available readout modes and āReadoutModeā sets the integer value of the mode. I donāt know about the ASI cameras, but the QHY cameras have the option of preset gain and offset values in the ASCOM driver. Since these are indeed readout modes, I would think that the driver developers could map these presets to the ReadoutMode property without worry of violating the spirit of ASCOM.
That way, SGP could substitute āreadout modeā for ābinningā for CMOS cameras in the sequencer. We could probably convince the camera developers to use the ReadoutModes property to reflect the preset readout mode settings. What do you think of that?
Tim
I am all for something like āactionā - because it lets the device maker directly offer new functionality and the user can choose to use it or not. I want to make the best use of available functionality as it appears - and some of that functionality may be device specific and not a long term, universal feature that all devices would support.
Apps like SGP would just need to allow an interface to allow the user to provide names of parameters to get/set - and SGP and ASCOM have no need to know what they are. Itās up to the user and the device maker to use them properly. Ideally SGP would also put any user selected items in the fits header also.
But back to the original request for āgainā - there is no GAIN value in the fits header when using the asi-1600. But it isnāt there for my Atik 383L+ ccd either. Even if I canāt set the gain value in the sequence - if it is available from a camera via ascom I would like it in the fits header. If you use the ASI with fixed values of offset and usb for each gain value, the gain value will tell you what you need. And that would be a big help for me.
Frank
I donāt think we would replace Binning with Gain. These are different concepts and SGP currently supports both so no need for one to go.
I plugged in my ASI 1600 to see if I could actually get gain from the ASCOM driver and it actually worked. We donāt have this exposed through SGP at the moment though. Currently we only support Gain for Qsi and itās gain values are āLowā and āHighā where the ASI can go from 0 - 600. So while itās possible to expose it weāll need to do some work to figure out how to get it in the UI in a decent way.
From a UI design perspective this sounds horrible. I can certainly see the benefit of it in that all devices can essentially specify their settings in whatever way they want without having to care about anything. But at some point we have to actually use those things in a meaningful way and display them so it doesnāt look like a mass of checkboxes and dropdowns haphazardly dropped on a form and poorly smashed together. Thankfully there is already a means of doing this which is the ASCOM Settings Dialog. The client application doesnāt have to care and you can still get access to those values.
Thanks,
Jared
Next beta will have GAIN and EGAIN (Electrons per ADU) for ASCOM Cameras. Both as specified by the camera, when available.
Thanks,
Jared
Great! Thanks Jared. As far as the ASI goes - this will work well for those of us who use specific combinations of gain and offset.
As for the crazy ui stuff - yes it would be ugly but Iām not sure how standardized these cameras will be over the years - and it may be a zoo either way. Things seem to be evolving.
Frank
Interesting thread - it did occur that with the very active CMOS sensor development going that sooner or later the astro community would need to consider how to get the best out of them and what changes that would drive to hardware and software. Addressing gain linearity will be one of the challenges I guess - driving a new form a calibration maybe.
Experimental purposes only!
If interested to see if your ASCOM Camera driver supports Gains or GainMin/GainMax
ASCOM V2 Camera reference:
http://ascom-standards.org/Help/Platform/html/T_ASCOM_DeviceInterface_ICameraV2.htm
A simple ASCOM javascript (in a zip file)
http://www.astrogene1000.com/ASCOM/checkascomcamforgain.zip
Download and extract to someplace on your harddrive
It is just a text file, you can read the contents with a right click on file->OpenWith->Notepad
Launch a Command prompt window
In the CMD window, navigate to where you extracted the contents to
Execute
cscript checkascomcamforgain.js
You will be presented a Chooser, select your camera and click āOkā
If you get an error about 32bit, use this instead
c:\windows\syswow64\cscript.exe checkascomcamforgain.js
Experimental purposes only!
Gene
Just FYI the next beta will support setting gain for ASCOM cameras, provided your camera supports it.
Thanks,
Jared
Hi
As a newbie to SGPro can you clarify what this means in practical terms. I Have an ASI1600 camera and currently set the gain and offset in the camera driver settings. Do I simply carry on doing this and setting SGPro gain as āNot setā? or do I have to do something else?