16 bit or 12 bit

[sharpie78]

Hi all,
I'm using a ZWO ASI1600MM-PRO (12bit ADC) which creates 16bit .FITS files....... when using SFS, BasicCCDParameters scripts etc......
should I be putting 12 bit or 16 bit into the sections where it asks for camera properties etc?
Also when it asks for max ADU etc should I be entering the 4095 ADU (12 bit) or 65504 (16 bit) measured with Statistics from a saturated flat ?
If I use the 12 bit numbers in BasicCCDParameters I get numbers close to the manufacturers website so kind of logical that I should use those. However....I'm processing 16 bit .fits files though so it has me wondering.
Main reason I would like to know is for SFS. Want to make sure I'm using the best subs I've got. I've been using the 16bit gain values from the fits header and it works fine. Problem is I read conflicting information online. Figured it best to check and ask the wealth of knowledge on here.
Many thanks in advance......over to you guys.......
Jack

[jwaters125]

I can't answer your question but I am sure somebody at Cloudy Nights can.

[pfile]

the thing is there's no such thing as a 12-bit or 14-bit fits file; for integer samples i think only 8, 16 and 32 bits are defined. so that's why you have 16-bit fits files. as you've found the correct thing to be doing is specifying that the files come from a camera with a 12-bit ADC.

rob

[sharpie78]

Thanks guys, I'll have a root around on cloudy nights to see if someone can explain it to me. As I said, what I'm doing works but I like to understand what I'm doing rather than just follow instructions.
Cheers
Jack

[dave_galera]

Jack,

The camera you are using is 12bit (most astro cameras are 16 bit) and the cameras binary values are simply saved as a 16 bit word with the unused bits set to zero
i.e. 0000 nnnn nnnn nnnn

You basically can't save a 12 bit word, so it has to be a 16 bit word

What else do you want explaining?

[wadeh237]

I find this a bit confusing as well.

For one thing, either the driver for the camera or the capture software (SGP) is bit shifting the pixel values for my ASI1600MM-cool to make them 16 bits in the FITS file.  But it's not doing them as "0000 nnnn nnnn nnnn", it's doing them as "nnnn nnnn nnnn 0000".  So the 16 bit pixel values in the FITS file are between 0 and around 65535 and always divisible by 16.

Since PixInsight works with normalized values in the range of 0 to 1, I'm assuming that any processes or scripts that use gain and bitness for input, are just doing the math internally.  On that assumption, I have measured the gain for the settings that I frequently use and have recorded the values as both 12 bit and 16 bit.  I figure that if I tell a process or script that the camera is 12 bits, then I need to provide the gain in terms of 12 bits.  And if I tell a process or script that the camera is 16 bits (which is what the FITS files look like), then I express the gain in terms of 16 bits.

For processes that use read noise as input, I need to make sure that the gain and read noise are both expressed in the same bitness terms.

For example, here is the gain and read noise information that I've measured and recorded for my camera:

Setting   : Gain=200, Offset=50
Gain      : 0.478e-/ADU @ 12 bits
Gain      : 0.030e-/ADU @ 16 bits
Read Noise: 1.424e-

Setting: Gain=76, Offset=40
Gain: 1.972e-/ADU @ 12 bits
Gain: 0.123e-/ADU @ 16 bits
Read Noise: 2.064e-

And here are the values that I use for MureDenoise.  Note that I'm using the 16 bit gain values, so I'm dividing my read noise values (expressed in electrons) by the gain at 16 bits to get the value I provide.  (Actually, if you do the math, you'll see that my read noise is just a small amount different from what you get by doing the division that I just described.  I assume that the Read Noise that I recorded for MureDenoise was actually measured independent of my original camera values above, and probably on another day.)

Gain 76, Offset 40:
    Gain             = 0.123 e/ADU
    Read Noise = 16.743 ADU

Gain 200, Offset 50:
    Gain             = 0.030 e/ADU
    Read Noise = 47.726 ADU

I hope that this makes sense.  And if I am way off base, I would love to be corrected.

Thanks,
-Wade

[pfile]

hard to know if it is the driver or SGP but SGP does call the canon raw handling software with flags that cause the 14-bit data to be expanded into a 16-bit space. im not surprised to see your report of left-shifted data since i suppose there is no standard for what to do with non-16bit ADCs.

so i suppose OP needs to look carefully at his fits files and determine if there are any values over 0.125 in the data, which would be a hint about how to handle the data. if it has been left-shifted then using 16-bit in all the PI statistics tools is the right thing to do. and your conversions to electrons seem correct to me.

rob

[sharpie78]

After doing some reading on cloudy nights I came across Jon Rista. His reccomendation is to use 16bit as the readout depth and 12bit/4095 in the camera resolution sections of the BasicCCDParameters script. When I do this I get very close to the values reported by manufacturer or when a sensor analysis is done in SharpCap.

I'm going to take that as a sign that it is the correct way to go....even if I don't fully understand why....frankly I grasp the concept but the Maths escapes me completely...left shifted, values over 0.125....above my head. Be handy if I knew what  12bit or 16bit word meant too. haha.

I've found that when using SubFrameSelector....if I put 12 bit in the camera resolution and a value of 2.091 in the gain sections (2.091 being the gain in e/ADU FITS header and also very close to what I measured) everything works fine. I'm certainly not quoting him but Jon mentions in his post that PI is very clever and is able to do whatever it needs to do when given the info that the camera is 12bit but the FITS files are 16bit. Thank goodness for PI I say. I think I'm just going to accept that I won't fully grasp this one yet.

Thanks for your input chaps
Jack