ASI1600 Camera. Pixinsight Image Statistics. ADU count

[PKay]

To continue with analysis of the ASI1600 working toward ideal GAIN and Sub length.
Once again this is only my take on things (I have to start somewhere).
This is not definitive information.
Please correct me if I am still wrong.

Once again using Shiraz’s formula as a starting point.
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

It is easy enough to calculate the Target ADU from the camera specifications.
In my case (previous post) it works out to be 51 ADU at unity gain.

So then, I have to analyse one of my LIGHT images to see just what is happening.
For example what is the average background ADU (K) value?
The ASI1600 uses a 12BIT ADC.
I posed a question to ZWO about this and the response was:
‘The ADC is 12bit but software save the 12bit data in the high 12bit of 16bit format’.

In Sharpcap I can select RAW16 saved in a .fits file.
This results in an image of 31.264 M bytes.

When I take an image, the ASI1600 represents each pixel with a value from 0 to 4096 (12 bits).
The BIAS is included in this (from 1 to 50), so insignificant.
Sharpcap then takes this number and writes it into a 16bit format.
As said above, this is in the high end of the 16bits (this is like multiplying the number by 4).

But how does this effect the operation of the Statistics tool in Pixinsight?
After a simple test on BIAS images (see previous post), the numbers match precisely when I choose a 12bit ADC in the tool.
I can only guess, but the Statistics tool must ignore the low 4 bits in this case ie: interpret the 16bit number as a 12 bit number.

In summary, for me to get the correct ADU value for analysing images, I have to select 12bit in the tool.
This will show ‘Full Well’ at 4095.
This ADU (K) value should correlate with the target_ADU value of 51 calculated earlier.

Also, I think I have worked out there is no need to Debayer the image or stretch it, to use the STATS tool, in other words evaluate the RAW . fits file.

Help appreciated.

[Camelopardalis]

Peter, the ZWO driver just adds 4 zeros to the LSB (small number) end of the 12-bit output to make a 16-bit FITS file, so using binary arithmetic, that has the effect of multiplying the true readout by 16.

I find it easier just to work in 16-bit, since this is what the data is recorded in, and to keep all the parameters in the same scale I have to divide the gain by 16 in the target ADU formula.

Take a bias frame, of around 1 second in duration, and measure the median background value. I use a simple tool called FITS Liberator, although you could do this in PixInsight just as well, using the Image->Statistics module. Then change from Normalized (default) to 16-bit integer. That is your BIAS value in the formula.

As an example, with the settings I use my Target ADU comes out around 1000 (16-bit). When I'm shooting a test LIGHT frame, I aim for a sky background ADU of 1000 or around that. Just remember this is 16-bit. Simples.

I think where you're tripping up is you're confusing yourself with the 12-bit thing, which is a bit of a red herring in practice.

[PKay]

There is still a few gaps to fill in.
Most of this is recap, however I have added thoughts about Full Well.
Also have reached (for me) a definitive conclusion about the ideal GAIN setting.
Once again, please contribute. It has been through all of your help that I have got this far.

The ZWO1600 camera uses a 12 bit ADC.
The maximum number it can output is 4095.
It doesn’t matter what GAIN setting, the max. output is still 4095.
The Full Well of the camera is 20k electrons. How does this work?
Example:
At unity GAIN (Sharpcap GAIN setting of 139) it takes one photon to generate 1 electron for the ADC to output the number 1.
At GAIN of less than 1, ie: 0.5(Sharpcap GAIN setting of 75), it would take 2 photons/electrons to output the number 1.
This interpretation can be seen by looking at the FW(e-) graph in the ASI1600 specifications.

Another way of saying this is:
At GAIN = 139 (unity) we gather 1 photon/electron for 1 ADU. => 1e/ADU => 4095 electrons Full Well
At GAIN = 75 we gather 2 photons/electron for 1 ADU. => 2e/ADU => 8200 electrons Full Well
At GAIN = 0 we gather 5 photons/electrons for 1 ADU. => 5e/ADU => 20,000 electrons Full Well.

So what does this mean, and how do we use this information?

But before I try and answer that, there is the issue about the 12 bits being made a 16 bit number by Sharpcap (or other software).
12 bits is the maximum resolution that can be had. It doesn’t matter if this 12 bit number is then converted into a 16 bit format. It is still the same information, just ‘scaled up’ in a linear way (multiplied by 12).
It does matter when we use Shiraz’s formula. He calls for a BIAS value that is supplied by the manufacturer. However, by taking a BIAS image (cap on, fast exposure) the Statistics tool can give a value.
For example:
I set the BIAS (BRIGHTNESS) in Sharpcap to a value of 20.
The camera is at -20C (most important).
I take a BIAS IMAGE and then analyse it using the Statistics tool in Pixinsight.
If I set the tool to 16 bits, the K (ADU) value is 300 (the BIAS setting has been multiplied by 16 due to the 4 bit shift).
If I set the tool to 12 bits, the K (ADU) value is 20 (the same as the BIAS setting).
It doesn’t matter what you choose, but the tool setting must be the same for later evaluation.
Personally I will use the 12bit setting in the PI tool. It just seems logical.

Now back to how many photons/electrons to use (or gather) to make up one ADU.
I think this is now the Crux of the whole matter.

It all comes back to the best SNR (Signal to Noise Ratio).
I know that this is basic information, but I have to spell it out…

Noise is random in nature. It will tend to spread itself throughout all the pixels in the camera array.
The Signal (hopefully) will tend to gather in specific pixels.
The more Signal we get, the better or the more photons/electrons we gather the better.
And there is a point where the amount of noise will over ride everything. Ie: if we exposed for 2 hours, all you would get is noise. The signal would get lost.

This is where the likes of Shiraz’s formula kicks in. (Target_ADU=BIAS + 10*RN*RN/GAIN).
Remember that GAIN in this formula is e/ADU (Not the GAIN setting found in Sharpcap), and is found in the ASI1600 specifications.

Next I used the results of this formula for Sharpcap GAIN settings of 0, 50, 100, 139(unity), 150, 200.
Values of e/ADU and RN were taken from the ASI1600 specifications for each GAIN setting.
The BIAS was set to 50 in all cases.

See the attached image.


The graph clearly shows a knee at GAIN 100 (Sharpcap setting) which equates to about 1.5 e/ADU and also equates to a Full Well of about 6500 electrons.
It can also be noted at this point, the RN (Read Noise) starts to climb more quickly for lesser values of the Sharpcap GAIN setting.

So what conclusion to draw from all this information?
I am going to set my BIAS (BRIGHTNESS) to 50, and forget all about it. Never touch it again.
I am going to do trial images at varying exposure times with Sharpcap GAIN set to 100 .
At Sharpcap GAIN = 100 the Target_ADU = 53 ADU.
Evaluate the images using the Statistics Tool in Pixinsight (with the tool set to 12 bits).
And then see what results
This might take some time because of the resident cloud that sits over my house…

[Camelopardalis]

You’re not understanding the gain correctly....

The full well is always the same, 20000 or whatever it is. When we expose, the number of photons each photosite receives doesn’t change (well, it does, but that’s a different matter altogether!). What happens is that the amplifier scales the output to fit between 0 and 4095 (note that this is actually 4096 values, which equals 2 to the 12th power) by different amounts, depending on what gain setting we choose.

It doesn’t matter whether you operate in 12-bit or 16-bit, so long as you’re comfortable with the calculation.

You could expose for two hours, but it would likely fill up the wells and full wells are full wells regardless of the gain. A full well would be represented by 4095, multiplied by 16 for writing to FITS.