ASI1600MM-P BIN mode and Bit depth

[mAnKiNd]

Hi - help!

I'm super confused with what bit depth I'm getting with the native (and ASCOM see below) driver for this camera when I bin and I'm sincerely hoping someone here can help clarify this for me. My confusion arises from the wording in the manual:

asi1600 manual.png (128.62 KiB) Viewed 2861 times

If I acquire a software bin1, I can safely assume that the ADC output is 12bit and is upscaled to 16bit:
https://drive.google.com/open?id=1G8vxk ... qK-xv3Z1mH

If I acquire software bin2, I should assume that the ADC output is still 12bit upscaled to 16bit, no;
https://drive.google.com/open?id=1nUbr0 ... WqsqPZgiHp

If I acquire hardware bin1, I should assume that the ADC output is still 12bit upscaled to 16bit, no;
https://drive.google.com/open?id=17k-rW ... pd29vcvn9G

However, if I acquire hardware bin2, I should now assume the ADC output is 10bit upscaled to 16bit, right;
https://drive.google.com/open?id=1T67Bi ... _Z1mAasSoA

I'm not sure how to reverse engineer the 16bit FITS file to check, other than looking at the histograms, of which the hardware bin2 is significantly brighter and coarser in appearace.

Turning on the "save 10/12/14 bit images..." (filename in link is called "noscale") option in settings, would allow me to check and confirm this no;

"noscale" Software bin1: https://drive.google.com/open?id=121qzi ... QqmuQAOnzE
"noscale" Software bin2: https://drive.google.com/open?id=19fIhb ... 9lwqJovk0z
"noscale" Hardware bin1: https://drive.google.com/open?id=1VtKXK ... Z2vVwCwJwq
"noscale" Hardware bin2: https://drive.google.com/open?id=1YL37D ... 2X02FsgZu-

However, I can't tell from the file metadata, again oly looking at the histogram appearance.

Does one know how to explain to me how one can reverse engineer from the 16 bit FITS file what the original ADC output was? I've opened each file in pixinsight and fits liberator software to look at the maximum ADU in each FITS, following the logic that:

16bit: 65,536
12bit: 4096
10bit: 1024

I get counfounding readouts (at least to my small brain) and my head ends up spinning in madness and I'm not sure I'm interpreting a correct answer for my question. I think I am suffering from "analysis paralysis"

Final question, I would like to know, for academic reasons, how the ASCOM driver behaves for bin1 and bin2, again with respect to bit depth:

ASCOM bin1: https://drive.google.com/open?id=1B2Kkw ... 8pKhszxFt7
ASCOM bin2: https://drive.google.com/open?id=1q5Dyd ... qcb4Ese9vA
"noscale" ASCOM bin1: https://drive.google.com/open?id=1zv_hJ ... 2e06K0e6ZK
"noscale" ASCOM bin2: https://drive.google.com/open?id=1BDpnE ... krOF-l2MMM

I'm sorry if I'm confusing a very simple matter, but what I hope to achieve here, is a simple yes or no confirmation that if I software bin2 with the native driver (or bin2 in the ASCOM driver), that I am indeed retaining the 12bit ADC output upscaled to 16bit. I want to avoid 10bit ADC, as I'm imaging deep sky objects, not looking for fast video fps.

Thank you so much for any clarifications you can provide,
Minos

[mAnKiNd]

I found these two answers on the Q&A of the product page, which I think helped clarify my confusion, or add to it, not sure...

[oopfan]

Minos,

Katherine Tsai's reply is correct but she needed to devote more time to her answer.

The example I'll give is for my CCD camera:
Atik 314E
16-bit ADC
Full Well Depth: 13762 electrons
Gain: 0.21 electrons per ADU
Hardware Binning

Let's say I focus the camera on an evenly-illuminated gray card.
I adjust the exposure so that the mean pixel value in the frame is 65535 ADU.
The mean number of electrons per pixel is therefore 65535 * 0.21 = 13762 electrons.
When I capture a frame in bin2 mode the number of electrons in the binned pixel is 4 * 13762 = 55048 electrons.
(So yes, Ms. Tsai is correct that your Full Well Depth is 4 times greater.)
But what happens when those 55048 electrons are input into the ADC? You get 55048 / 0.21 = 262133 ADU.
Unfortunately the ADC is not an 18-bit A/D so the answer is clipped at 65535 ADU.

Brian

[oopfan]

Minos,

Hardware binning is frequently used when capturing RGB with a mono camera.
The advantages are (1) higher signal-to-noise ratio, (2) shorter exposures than bin1, (3) smaller image files.
The disadvantage is lower spatial resolution but that is all right since we rely on the luminance channel for detail.

I am not familiar with software binning but from what I've read you only get two of the three advantages that I listed above. You don't get the higher signal-to-noise ratio. (Please someone correct me if I am wrong.)

Now, this is me thinking off the top of my head, your CMOS camera has the advantage of adjustable gain. Remember my example in the previous post where the binned pixel might contain 55048 electrons? With my single-gain camera the ADC would clip the result but there is a possibility with your CMOS camera that you could select a low gain to prevent clipping! So you could get the advantage of higher SNR using hardware binning AND take advantage of the higher effective Full Well Depth.

I would be interested in what others have to say. I could be all wet!

Brian

[oopfan]

Minos,

I would recommend going to the sensor manufacturer's datasheet. I would imagine that it is Sony. Chip manufacturers are in the business of selling their products to professional electronics engineers around the world. Their command of the English language is much better than what you get from ZWO.

Brian

[mAnKiNd]

Brian, thank you kindly for all your effort. I think the situation here with the ASI1600 is more complex. To quote a user from cloudynights:

"On the ASI1600, the ADC output for native resolution is 12 bits. The ADC output binned 2x2 is 10 bits. This per the manual."

But the in the screenshot of Sam's response above, he says binning in APT is software, which should be 12bit as per the manual! This is so frustratingly confusing. What bit depth is this cameras ADC output converting to 16bit FITS files with? Is it 10 or 12!?

My confusion arises from the terms "software" and "hardware" binning, with software binning claimed to be 12bit and hardware binning to be 10bit. Btw, it's not really "hardware" binning like a ccd, but from what I understand, It's a wrongfully used term to denote in-camera driver binning.

What I need to clarify with the ASI1600 is a YES/NO answer to these questions:

1) Using the ZWO native driver in Sharpcap, if I choose bin2, is the ADC output 12bit -> 16bit? YES/NO

2) Using the ZWO ASCOM driver in Sharpcap, if I choose bin2, is the ADC output 12bit -> 16bit? YES/NO

3) In Sharpcap, using the ZWO native driver and enabling the hardware binning option, if I choose bin 2, is the ADC output 10bit -> 16bit? YES/NO

These are the three possible scenarios to bin this camera in Sharpcap. If the answer is yes to #1 (or #2, but prefer to use native), then were good to go with binning and DSO. If the answer is no to #1 and #2, then binning on this camera and rendering it 10bit is not viable for deep sky work, unless one acquires thousands of frames to recover bit depth, which I won't!

I have included in the op links to FITS files I acquired under every possible binning scenario. I hope someone can answer the question of binning and bit depth with the ASI1600.

Minos

[mAnKiNd]

Minos,

I would recommend going to the sensor manufacturer's datasheet. I would imagine that it is Sony. Chip manufacturers are in the business of selling their products to professional electronics engineers around the world. Their command of the English language is much better than what you get from ZWO.

Brian

ASI1600 chip is from Panasonic, model # MN34230ALJ

I will try to look for an answer from the manufacturer.

[oopfan]

Hi Minos,

I don't know if you can rely on what other people say. The world is rife with people who like to theorize but not experiment.

I would suggest finding a 8th to 10th magnitude spectral class "G" star and capturing a few dozen frames with your green filter in all of the configurations you are interested in. Calibrate them, stack them, and measure them using AstroImageJ.

It is the only way you will know for certain.

Brian

[oopfan]

Minos,

You also need to capture frames in bin1 mode so you can compare them to what happens when you switch to the different flavors of bin2.

1. Focus in bin1.
2. Set the star's max pixel value to 8192 ADU.
3. Capture a set of frames in bin1.
4. Using the same exposure, switch to bin2 and capture again.
5. Finally, set the star's max pixel value at 24576 ADU in bin1.
6. Capture frames at bin1 and then bin2. This will show what kind of clipping is happening.

Brian

[mAnKiNd]

Brian, that's a good idea, thank you. Couple of questions of clarification.

When you say set the stars max pixel value to xxxx, is this something in Astroimagej? Sorry, I'm not familiar with it.

Considering we are clouded out for the next week and I might not get a chance, would conducting this test indoors with an artificial star be ok? I have this product:

https://www.cameraconcepts.com/hubble-5 ... stars.html