SGP 2.6.0.13: ASI1600 gain return to 0

[jon.rista]

Chris, just to make sure I understand…

You are not suggesting that a dark frame acquired at Gain 0 on an ASI1600, which would be 4.88e-/ADU and a default offset of 10 ADU, would be the same as a dark frame acquired at Gain 139, which would be unity with 1e-/ADU and an offset of 10 ADU, are you? Since the offset is in ADU, it would be 10e- @ unity, while ~48.8e- @ Gain 0. So darks acquired at one gain setting couldn’t be used at another anyway.

Since read noise does drop at higher gain, and with dark current as low as it is (on the order of 0.005e-/s for most of these modern CMOS cameras), and with exposures being pretty short at higher gain settings, it is not necessary to use a large offset at higher gain. However, you do want to make sure you have a sufficient offset. An offset of 10 ADU is probably overkill for Gain 0, and an offset of 10 ADU is most likely insufficient at unity or higher gain settings.

Additionally, how you use the camera could play a role in how much dark current you have to account for in the offset. This could depend on aperture and f-ratio, how dark your skies are, etc. Someone using a large aperture fast refractor (such as myself, 150mm aperture on a 600mm focal length at f/4) is generally forced to use pretty short exposures across the board. Someone using a much slower scope, say a large SCT, might need significantly longer exposures to get a similar pixel signal. They would incur more dark current with those longer subs, so may need a different offset.

Fundamentally, we need the ability to optimize the offset with the gain, as a single offset isn’t going to pair well with every gain setting. Variable offset gives each user the ability to optimize the camera for their usage.

[Chris]

@jon.rista

You are not suggesting that a dark frame acquired at Gain 0 on an ASI1600, which would be 4.88e-/ADU and a default offset of 10 ADU, would be the same as a dark frame acquired at Gain 139, which would be unity with 1e-/ADU and an offset of 10 ADU, are you? Since the offset is in ADU, it would be 10e- @ unity, while ~48.8e- @ Gain 0. So darks acquired at one gain setting couldn’t be used at another anyway.

A gain of zero gives an output of zero. Anything times zero is zero.

I’ve no idea what ASI mean by “Gain 0” but if the output varies depending on the output then it’s not zero. Maybe it is an index into a set of gain values. If that’s the case then only they know what gain they are actually using.

You have said that you want the no signal value to be a positive value and far enough from zero that the whole of the zero signal is recorded - to the two sigma level would be reasonable. That’s perfectly sensible but if that’s the case adjusting the offset to allow for sky fog is irrelevant and undesirable. There’s no reason not to use a manufacturer specified offset value that’s appropriate for the gain and ensures that the no signal short exposure signal is enough above zero to give a valid zero value. No need to set the offset, trust the manufacturer. No need to read it, just apply bias, dark frame and flats to the raw data.

[jon.rista]

Sorry, the scalar numbers refer to ZWO’s gain settings range. ZWO cameras usually have a gain setting range from 0-600. IIRC, this is 10x the decibels of gain, so at 600, the gain would be 60dB (but don’t quote me on that just yet, I’ll have to check and verify.)

QHY uses similar settings, however I believe their range is 0-50.

So when we ZWO or QHY camera users refer to “Gain 0” we are actually referring to the ASCOM driver SETTING value, not the literal gain. My apologies for the lack of clarity there.

The actual conversion gain ratio at “Gain 0” setting on the ASI1600 is 4.88e-/ADU (at least, that was my measurement when I evaluated the sensor). At “Gain 139” setting, or unity gain, the actual conversion gain ratio is around 0.987e-/ADU (again, as I’ve measured it…technically speaking it should be 1e-/ADU). At “Gain 200” setting, I’ve measured 0.483e-/ADU, etc.

Generally speaking, few ZWO ASI USB 3 cameras are really viable above Gain 300 setting. Most of them have a conversion gain ratio there of around 0.1e-/ADU or higher. So, depending on the exact camera you are using, the literal gain ranges somewhere from ~5e-/ADU down to 0.1e-/ADU, and I would assume that most of the time, the actual gain settings used are minimum gain, unity gain, or a gain setting where the conversion gain ratio is around 0.5e-/ADU (this is why I usually use Gain 200 for narrow band, it’s close to 0.5e-/ADU which I feel better samples the noise than 4.88e-/ADU. ;P)

So when we referr to “Gain 0”, we are not referring to a literal gain of 0x, we are just referring to the ASCOM driver’s gain setting.

[Chris]

My post escaped before I had finished it, I’ve edited it slightly.

I am totally convinced by the need to modify the gain setting and if what you get is an index into the real gain settings then so be it. But I’m less convinced that offset is needed as a separate property available to the user.

I have not seen a convincing reason why gain needs to be available to the user as a separate setting. In other words for a single gain setting why would a user need to set different offset values?

[jon.rista]

Chris, just out of curiosity, have you used one of the ZWO or QHY CMOS cameras? Namely the ASI1600 or QHY163? If you actually take a look at the driver, up front there are just two sliders. Gain and offset. The manufacturer did provide a handful of presets…usually a maximum DR, unity and minimum read noise preset. There are offsets preconfigured for those settings…however, many of us have done testing and determined that other gain settings are more optimal. Those custom gain settings do not have preset offsets.

For the record as well…I am not sure that the default offsets in the presets are always most optimal. I’ve had clipped black pixels (well, due to how the driver scales 12-bit data into 16-bit, they end up as a value of 1, rather than 0) at unity gain and the minimum read noise presets. It’s a tough balancing act at higher gain with these cameras. On the one hand, you want to increase offset to eliminate any and all black clipping, however on the other hand, the more you increase the offset the more you eat into dynamic range and risk clipping stars.

In some ways, having a small number of clipped black pixels is preferable to clipping stars, since with dithering and sigma clipping you can easily reject those outlier noise pixels. However…clipped stars are clipped stars, as once you clip noise drops to zero, and you are aligning on the stars as well. So a clipped star is always a clipped star, there are no processing techniques that could resolve that…not like clipped black pixels anyway.

I think there are reasons to use offset as a means of optimizing results for the optical system and skies. In my case, I tend to need to keep my offset low and I compromise with some black pixels. Someone with a slower, high resolution optical system and darker skies could certainly increase the offset and avoid all clipping, as they might not use up all the available dynamic range anyway. When you get down to it, and fully optimize the gain and offset for your particular setup, I think you will find that more often than not, you are using a custom gain and offset setting, rather than one of the very few preconfigured ones…so just letting the manufacturer take care of offset for you is not really an option.

Oh, one other thing to keep in mind with modern CMOS cameras. They can easily do double duty as both DSO (deep sky) and SSO (solar system) imaging. Many of us do indeed use these cameras for both purposes. Readout speed on these CMOS cameras, thanks to the fabrication technology and support for ROI (region of interest, a way of reading out only a configured area of the sensor), is extremely high (hundreds of FPS) while maintaining the low read noise. The freely variable gain is quite useful with planetary imaging, and you can often use a higher offset than the defaults (if there is one) to ensure you don’t clip any pixels to black, since you don’t often need 12 stops of dynamic range with planetary.

[Chris]

@jon.rista

Chris, just out of curiosity, have you used one of the ZWO or QHY CMOS cameras? Namely the ASI1600 or QHY163? If you actually take a look at the driver, up front there are just two sliders. Gain and offset. The manufacturer did provide a handful of presets…usually a maximum DR, unity and minimum read noise preset. There are offsets preconfigured for those settings…however, many of us have done testing and determined that other gain settings are more optimal. Those custom gain settings do not have preset offsets.

I haven’t used these cameras, but that is irrelevant. These cameras still operate according to the laws of physics.

If you think that the default offset values for these cameras, supplied by the mount manufacturers, are incorrect then that’s something to take up with them.

@jon.rista

I think there are reasons to use offset as a means of optimizing results for the optical system and skies. In my case, I tend to need to keep my offset low and I compromise with some black pixels. Someone with a slower, high resolution optical system and darker skies could certainly increase the offset and avoid all clipping, as they might not use up all the available dynamic range anyway. When you get down to it, and fully optimize the gain and offset for your particular setup, I think you will find that more often than not, you are using a custom gain and offset setting, rather than one of the very few preconfigured ones…so just letting the manufacturer take care of offset for you is not really an option.

When I suggested that you wanted to using a low offset to compensate for sky glow you said that this is not what you wanted to do. Yet this seems to contradict this. If you set a low gain and accept that unilluminated pixels will record the minimum this is what is happening.

I don’t see a reason why the user needs control of offset. I can see that there may be a reason to adjust the default offset values applied for a specific gain setting but not a reason to require that this be routinely available. Maybe it’s something that would be better sorted in the driver.

BTW I don’t see a fundamental difference between CCD and CMOS detectors. They both convert light into electrons and store the electrons in pixels. the read out mechanism reads the number of electrons and converts that to a number.

The only difference is that the ADC in CCD cameras will typically convert to a 16 bit number while CMOS detectors are fixed at 12 bits - 0 to 4095. CMOS pixels can contain something like 20,000 electrons so for the full well depth you need a gain of something like 4 electrons per ADU value. That’s a gain of 0.25 electrons per ADU. If the gain is increased to 1 electron per ADU then the maximum number of electrons you can measure is 4095. These gains may need different offsets to ensure that the zero electron value isn’t less than zero but nothing more.

CCD detectors don’t have this problem. With a pixel well depth of 25,000 to 50,000 electrons the full range of the CCD can be accommodated in the ADC range of 0 to 65535. No need to worry about gain or offset. If you can count the electrons in each pixel that’s as good as you can get.

@jon.rista

Oh, one other thing to keep in mind with modern CMOS cameras. They can easily do double duty as both DSO (deep sky) and SSO (solar system) imaging. Many of us do indeed use these cameras for both purposes. Readout speed on these CMOS cameras, thanks to the fabrication technology and support for ROI (region of interest, a way of reading out only a configured area of the sensor), is extremely high (hundreds of FPS) while maintaining the low read noise. The freely variable gain is quite useful with planetary imaging, and you can often use a higher offset than the defaults (if there is one) to ensure you don’t clip any pixels to black, since you don’t often need 12 stops of dynamic range with planetary.

Sure, but you don’t apply bias, dark and flat fields to planetary images.

[jon.rista]

I am not sure how to properly quote on these forums, there does not seem to be an option to quote the post you are replying to. Anyway, first things first. CMOS cameras are NOT all 12-bit. Some are, most are 14-bit, and I think there are a couple out there that are 16-bit (Leica, namely). Most modern CMOS sensors are 14-bit, I think the one in the ASI1600/QHY163 is a bit of an outlier being 12-bit (and I think that is only the case because it was one of the few monochrome CMOS sensors manufacturers like ZWO could get their hands on at a good price to keep their costs low and their retail prices reasonable. I’m sure there will be 14-bit mono CMOS sensors, and probably in much larger form factors, available in the future.) There are some older planetary cameras that are also 12-bit, however again I think in general those are more the outliers than the rule for CMOS.

As for what I said…I said I never recommended using a ZERO offset, which seemed to be what you were implying before. However, I think you were looking at “Gain 0” and thinking that meant a literal gain multiplier of 0, which is not the case. I also said I don’t recommend using different offsets for calibration frames…as doing so effectively invalidates the calibration frames entirely (they need to match on all the critical factors, gain, offset at the very least, temp preferably for all but definitely for darks, and exposure length for darks.) You also seem to have missed my points about pixel rejection, which still applies to darks as well… shrug

As for the rest. We are kind of just talking past each other now. I think you need to use one of these CMOS cameras and actually do the work to optimize the gain and offset for your system before there would be any point in continuing the discussion. I think there is definitely value in a variable offset with these kinds of cameras, but I’m not going to keep arguing the point. I’ve said what I can say, not much more to add, and we are risking derailing this thread.

[alcol]

slightly off topic, but is there a way to record the ASI1600 gain and offset settings in the file/image naming? It may have already been answered but I couldn’t see it.

[Starship]

I put that information in the “offset” field of the sequence window. G90-O20 denotes gain = 90 and offset = 20, for example. What you enter is retained from sequence to sequence so you only have to enter your info once.

[alcol]

Presumably there is no way to change it mid-sequence if you want to, if you
are imaging broadband and narrowband as part of the same sequence?

[Starship]

I hope someone corrects me if I’m wrong, but I believe there is no way to change gain mid-sequence. However, if all you wish is to record your settings as part of the file name, the method I described above works great.

[Ken]

@alcol

Presumably there is no way to change it mid-sequence if you want to, if you
are imaging broadband and narrowband as part of the same sequence?

There will be shortly. The first pass will, in a slightly clumsy way, allow each event to use a custom gain. After this is complete we will build a more intuitive event options interface. Over the years, events have started to accumulate more options and information and they are in need of a better UI to help them grow more gracefully.