ASI1600MC-C ADU, Exposure time, GAIN & BIAS

[PKay (Peter)]

This information was posted on Saturday, unfortunately it disappeared into the ether after the crash.
I did have a few responses (thanks heaps).
I have incorporated those responses into this ‘take 2’, and since done a few more experiments.

Like everyone I am trying to work out the best exposure time, GAIN and BIAS settings.
It has taken me months of study to get this far, and please enlighten me if I am still wrong.
This is only my take on things. It is not definitive information.
What I am working toward (since I have a colour camera) is to preserve the dynamic range. If a star is blue, red or yellow I want to see it.
So far all my stars turn out white.
At the same time, I want to catch the misty stuff.
I have been reluctant to do any more imaging until I get this sorted.

As a starting point, and this really got me going… is Shiraz’s formula:
Target_ADU = BIAS + 10*RN*RN/GAIN is for a CMOS camera such as the ASI1600MM.
Ray says that the background ADU count should be slightly higher than the Target_ADU
So how do we get and use this information, and will this formula work for a colour camera?

I use Sharpcap and the BIAS is set by the ‘BRIGHTNESS’ control. This is also called OFFSET by others.
BIAS = BRIGHTNESS = OFFSET. They are all the same thing.
BIAS is simply a number that is added to the photon count (more on this later).

It has been said by some the ideal setting for the BIAS on the ASI1600 is dependant on the GAIN setting.
These BIAS settings are from the default ASCOM driver (so come from ZWO ??):
At GAIN = 0 => BIAS = 10.
At GAIN = 139 (unity) => BIAS = 20.
At GAIN = 300 (almost max) => BIAS = 50.
I think it turns out (read on) the BIAS setting is not so important. Set it at 20 and forget all about it.

The formula above needs GAIN to be in units of e/ADU
Using the specifications for the ASI1600:
GAIN setting of 139 (unity) translates to 1 e/ADU
Also at unity GAIN the RN (Read Noise) =1.7 e/rms
Use BIAS = 20 (for unity GAIN).
So plug these values into the formula and the Target_ADU = 51 ADU.
I now have a number of 51 ADU. So how does that help?

Next thought is what does ADU mean (aside from Analogue to Digital Unit) ?
Each pixel contains a photo diode. When a photon hits it, an electron is produced. The electron is stored in a capacitor which sets up an electric field which results in a voltage. This voltage (analogue) is then converted to a number using an ADC (Analogue to Digital Convertor). At unity GAIN one photon results in the number 1 (which is 1 ADU). Now the BIAS is added to this ‘photon count’ (in this case 20).

Now we talk about ‘FULL WELL’.
With the ASI1600 I can choose a 12 bit A to D convertor.
The maximum number it can output is 4095.
Using the ‘Statistics’ tool in Pixinsight (it must be set at 12 bit ADC):
It shows the white areas of an image have a K value (ADU value) of 4095.
At unity GAIN this translates to roughly 4095 photons have hit the sensor (noise from the photo diode can add a few ‘false photons’), and you can take away the BIAS value (which is about 20 in this case).
This indicates those pixels are fully saturated or ‘Full Well’.

I then performed a series of tests to evaluate how BIAS and GAIN setting affected the K (ADU) value found by using the tool.
I took 4 BIAS images (lens cap on, shortest exposure time).
With the ‘BRIGHTNESS’ (or BIAS or OFFSET) set to 0, 10, 20, 100.
The GAIN was set to 0.
In the PI Statistics tool, the K value (ADU) matched almost precisely with the BIAS value (using the median value in the tool).
Thinks makes sense (I am getting somewhere).

Then I set the BIAS to 0 and took 3 BIAS images with the GAIN setting 0, 139, 500.
Now it gets interesting.
At GAIN =0 the result for the BIAS median value came out at close to 0. Correct.

At GAIN=139 (unity) the BIAS came out at 2 (close enough), however I did notice the MAX value had jumped up to a value of 60 ie: At least one pixel had collected a K value of 60.

At GAIN=500 things went haywire. The tool showed the median K value (ADU value) at 1 (which is OK), however the MAX value skyrocketed to 3700!! Looking at the image I could see bright pixels all over the place.
What this is saying, is that GAIN settings of greater than unity are to be used with caution. Not to say you can’t use high GAIN settings, but you will end up with a lot of ‘false photons’, even before you start.
It may be the case that the DARK images remove all this noise, further testing required.

Back to that value of 51 ADU calculated earlier.
I evaluated one of my M31 LIGHT images (debayered ). It showed some red nebulosity however all the stars were white.
The median K value (ADU value) was about 200.
This value is obviously way to high.
The calculated value is 51. Mine was 200. Must be something in between…

In conclusion:
Previously my GAIN setting (200-250) and my BIAS setting (30) were way to high. I was using only 30sec exposure.
Soon, when the clouds clear, I will try the following settings (hopefully on the Jewel Box, or Pleiades) and then move on to (back to) Orion:
GAIN = 0. BIAS = 20. 30sec, 60sec, 120sec exposures.
GAIN = 139. BIAS = 20. 30sec, 60sec, 120 sec exposures.
Then fire up Pixinsisght and evaluate the results.

It addition, I feel the best images from the ASI1600MC are going to be the integration of several different GAIN settings and exposure times, and that will depend on the target and seeing conditions.
More on that later after some field testing…
Thanks for any input.

[kens (Ken)]

Originally Posted by PKay

This information was posted on Saturday, unfortunately it disappeared into the ether after the crash.
I did have a few responses (thanks heaps).
I have incorporated those responses into this ‘take 2’, and since done a few more experiments.

Like everyone I am trying to work out the best exposure time, GAIN and BIAS settings.
Concentrate on the gain. ZWO is moving towards a constant bias of 50 for simplicity and it has minimal impact on dynamic range
It has taken me months of study to get this far, and please enlighten me if I am still wrong.
This is only my take on things. It is not definitive information.
What I am working toward (since I have a colour camera) is to preserve the dynamic range. If a star is blue, red or yellow I want to see it.
So far all my stars turn out white.
Use the lowest gain for greatest dynamic range
At the same time, I want to catch the misty stuff.
Integration time is key here but its hard to not saturate the brightest stars
I have been reluctant to do any more imaging until I get this sorted.

As a starting point, and this really got me going… is Shiraz’s formula:
Target_ADU = BIAS + 10*RN*RN/GAIN is for a CMOS camera such as the ASI1600MM.
Ray says that the background ADU count should be slightly higher than the Target_ADU
So how do we get and use this information, and will this formula work for a colour camera?
From manufacturer data or by experiment. It will work with colour
I use Sharpcap and the BIAS is set by the ‘BRIGHTNESS’ control. This is also called OFFSET by others.
BIAS = BRIGHTNESS = OFFSET. They are all the same thing.
BIAS is simply a number that is added to the photon count (more on this later).
The electron count actually
It has been said by some the ideal setting for the BIAS on the ASI1600 is dependant on the GAIN setting.
As above - use a bias of 50 for ZWO cameras as in future drivers it quite likely wont be a variable
These BIAS settings are from the default ASCOM driver (so come from ZWO ??):
At GAIN = 0 => BIAS = 10.
At GAIN = 139 (unity) => BIAS = 20.
At GAIN = 300 (almost max) => BIAS = 50.
I think it turns out (read on) the BIAS setting is not so important. Set it at 20 and forget all about it.

The formula above needs GAIN to be in units of e/ADU
Using the specifications for the ASI1600:
GAIN setting of 139 (unity) translates to 1 e/ADU
Also at unity GAIN the RN (Read Noise) =1.7 e/rms
Use BIAS = 20 (for unity GAIN).
So plug these values into the formula and the Target_ADU = 51 ADU.
I now have a number of 51 ADU. So how does that help?
Thats a 12bit number. If your image stats are in 16 bit (which is more usual) multiply by 16. The you want the mean/median of your image to be at or above the target. At that point your sky background is at or above 10 time the read-noise squared so read noise becomes a non issue

Next thought is what does ADU mean (aside from Analogue to Digital Unit) ?
Each pixel contains a photo diode. When a photon hits it, an electron is produced. The electron is stored in a capacitor which sets up an electric field which results in a voltage. This voltage (analogue) is then converted to a number using an ADC (Analogue to Digital Convertor). At unity GAIN one photon results in the number 1 (which is 1 ADU). Now the BIAS is added to this ‘photon count’ (in this case 20).
Electron - not photon. But electron count is in proportion to photons hitting the sensor

Now we talk about ‘FULL WELL’.
With the ASI1600 I can choose a 12 bit A to D convertor.
The maximum number it can output is 4095.
Using the ‘Statistics’ tool in Pixinsight (it must be set at 12 bit ADC):
It shows the white areas of an image have a K value (ADU value) of 4095.
At unity GAIN this translates to roughly 4095 photons have hit the sensor (noise from the photo diode can add a few ‘false photons’), and you can take away the BIAS value (which is about 20 in this case).
This indicates those pixels are fully saturated or ‘Full Well’.
No - the full well of the ASI1600 can hold up to 20000 electrons. At unity gain, once the ADC counts 4095, every count above that still converts to 4095. So the signal is clipped. So at a gain of 2e-/ADU the ADC could count 8190 electrons before clipping/sturating.

I then performed a series of tests to evaluate how BIAS and GAIN setting affected the K (ADU) value found by using the tool.
I took 4 BIAS images (lens cap on, shortest exposure time).
With the ‘BRIGHTNESS’ (or BIAS or OFFSET) set to 0, 10, 20, 100.
The GAIN was set to 0.
In the PI Statistics tool, the K value (ADU) matched almost precisely with the BIAS value (using the median value in the tool).
Thinks makes sense (I am getting somewhere).

Then I set the BIAS to 0 and took 3 BIAS images with the GAIN setting 0, 139, 500.
Now it gets interesting.
At GAIN =0 the result for the BIAS median value came out at close to 0. Correct.

At GAIN=139 (unity) the BIAS came out at 2 (close enough), however I did notice the MAX value had jumped up to a value of 60 ie: At least one pixel had collected a K value of 60.

At GAIN=500 things went haywire. The tool showed the median K value (ADU value) at 1 (which is OK), however the MAX value skyrocketed to 3700!! Looking at the image I could see bright pixels all over the place.
What this is saying, is that GAIN settings of greater than unity are to be used with caution. Not to say you can’t use high GAIN settings, but you will end up with a lot of ‘false photons’, even before you start.
It may be the case that the DARK images remove all this noise, further testing required.
The larger max values are jsut a function of the amplification and also the random nature of noise. High gain is an issue for saturation but the read noise is lower as is quantization noise

Back to that value of 51 ADU calculated earlier.
I evaluated one of my M31 LIGHT images (debayered ). It showed some red nebulosity however all the stars were white.
The median K value (ADU value) was about 200.
This value is obviously way to high.
The calculated value is 51. Mine was 200. Must be something in between…

In conclusion:
Previously my GAIN setting (200-250) and my BIAS setting (30) were way to high. I was using only 30sec exposure.
Soon, when the clouds clear, I will try the following settings (hopefully on the Jewel Box, or Pleiades) and then move on to (back to) Orion:
GAIN = 0. BIAS = 20. 30sec, 60sec, 120sec exposures.
GAIN = 139. BIAS = 20. 30sec, 60sec, 120 sec exposures.
Then fire up Pixinsisght and evaluate the results.
If you are after dynamic range use the lowest possible gain. The target ADU iaims to overcome read noise for faint objects so bright stars could stil be saturated. The only solution if you want faint detail and unsaturated stars is a camera with more dyanmic range as givenby FWC/RN
It addition, I feel the best images from the ASI1600MC are going to be the integration of several different GAIN settings and exposure times, and that will depend on the target and seeing conditions.
More on that later after some field testing…
Thanks for any input.

My inputs in red above

[glend (Glen)]

Maximum well-depth, according to Jon Rista's work and Ray's chart, is achieved at Gain 76. There is no point in imaging at Gain 0..

[PKay (Peter)]

Thank you Ken and Glen for replying.

It has been a nightmare for me learning all this stuff, and your assistance is much appreciated.

It is no coincidence that some imagers out there get it right most of the time, and the results are stunning.

I will stew on this information for a few days (and wait for the never ending clouds to go away).

[ZeroID (Brent)]

Thanks for this little thread. I'm still getting my head around all the variables with the 1600mm-c. I'm using SharpCap so the information above is more relevant to me.

Going to print this out so I can 'stew on this' as well and add my own notes.

and wait for the never ending clouds to go away ..... <sigh>

[Camelopardalis (Dunk)]

One thing I've picked up from random threads around the interweb is that the output you get from grabbing the image through the ZWO SDK and via the ASCOM driver may not be same...although I haven't tested this, since I use the ASCOM driver exclusively (so far).

The end result could be that the calibration frames don't match if you recorded lights using something like SharpCap (that can actually use the SDK or the ASCOM driver - a good place to test!) but generate your darks using an ASCOM driven program, like APT or SGP. Not sure why you would want to do that, but it's something to be aware of.

Like I said, I haven't tested this myself so take with a cup full of salt...

[Camelopardalis (Dunk)]

Another point is...it's easy to get tied up in knots thinking about optimum settings with all those parameters to play with.

A good place to start is just unity. Maybe not the best in all cases, but it really depends on the target, location, etc.

Incidentally, the maximum dynamic range measured on my particular camera is gain 78, but I don't use that for imaging much. Each camera can have minute variations from others, but whether your a couple of gain values different from your astro mates doesn't really matter in the general scheme of things.

What's more important IMO is learning how to expose sufficiently.

[ChrisV (Chris)]

Originally Posted by Camelopardalis

One thing I've picked up from random threads around the interweb is that the output you get from grabbing the image through the ZWO SDK and via the ASCOM driver may not be same...although I haven't tested this, since I use the ASCOM driver exclusively (so far).

The end result could be that the calibration frames don't match if you recorded lights using something like SharpCap (that can actually use the SDK or the ASCOM driver - a good place to test!) but generate your darks using an ASCOM driven program, like APT or SGP. Not sure why you would want to do that, but it's something to be aware of.

Like I said, I haven't tested this myself so take with a cup full of salt...

+1. I got very different darks biases etc with the zwo and ascom drivers in sharpcap. Even when I set the brightness to what I thought was the offset equivalent in ascom.
It's easier now. The ascom for zwo cameras just sets the offset to 50.

I just go with unity gain and do 90 or 120sec subs. Just stick your values in the Shiraz spreadsheet. I'm guessing it should tell you that somewhere around there is optimal for this sort of cmos camera.

[glend (Glen)]

Originally Posted by ChrisV

+1. I got very different darks biases etc with the zwo and ascom drivers in sharpcap. Even when I set the brightness to what I thought was the offset equivalent in ascom.
It's easier now. The ascom for zwo cameras just sets the offset to 50.

I just go with unity gain and do 90 or 120sec subs. Just stick your values in the Shiraz spreadsheet. I'm guessing it should tell you that somewhere around there is optimal for this sort of cmos camera.

I think the new thinking of Offset 50 in the latest driver has not pleased some people. I have the driver that allows me to have full Offset control and my last setting is saved, so i rarely change it. There has been a lot of research done by Jon Rista and Ray on various setting combinations, but as Chris noted, many people just shoot at Unity and don't worry about messing around with it. This camera can be configured many ways, but really it almost gives you too much choice.
I would stay away from Sharpcap control, i realise its free, but i prefer SGP/ASCOM camera control.

[Camelopardalis (Dunk)]

It's only the newer model cameras that have the fixed offset.

I'm using the latest driver on my 1600 and still have the offset control slider.

[glend (Glen)]

Originally Posted by Camelopardalis

It's only the newer model cameras that have the fixed offset.

I'm using the latest driver on my 1600 and still have the offset control slider.

That is good news.

[ZeroID (Brent)]

SharpCap has the 'Brightness' control. I hadn't even touched it but it was set at 51 by default.
For some reason my adventures with SGP were not very successful. It's overly complex and unfriendly and I had connection stability and control issues with it. I may look at it again one day but Sharpcap seems to work first time.
I just can't find the 'Anti-Cloud' button though..