### Looking for Sensor Analysis/Statistics help & ideas

Posted:

**Mon Jan 22, 2018 10:07 pm**Anyone good with science/statistics? I'm looking for some thoughts on an anomaly I'm seeing with the sensor analysis of certain cameras....

I thought I understood how astro cameras worked in 8 bit mode and how I could generate a set of sensor analysis figures for 8 bit mode from those measured in a higher bit depth (ie 12 bit). The idea I had went like this...

The most important features of 8 bit mode (compared to 12 bit mode) are

* The ADU value is reduced to the range 0..255 from 0..4095 (by dividing by 16). This means the e/ADU figure is actually 16 times bigger for the same gain

* The read noise in 8 bit mode is dominated by inaccuracies caused by rounding when you divide the ADU by 16 in the first step above - for instance if the light level would give you a 12 bit adu of 3241, you get 202.5625 when dividing by 16, rounded to 203, an error of 0.4375

The second observation about read noise lets you predict the read noise for a camera in 8 bit mode - basically you assume that all the pixels that give you a readout of 203 really should have values ranging between 202.5 and 203.5 and assume an even distribution in that range. You can calculate the standard deviation of a uniform distribution of width 1, and it turns out to be 1/sqrt(12), or about 0.288.

This value of 0.288 shows up in the measurement of many sensors in 8 bit mode - basically it is the ratio between the read noise and the e/ADU gain, for instance an Altair 183C at minimum gain in 8 bit mode has Read Noise=18.13, e/ADU=62.96, which gives a ratio of 18.13/62.96 = 0.288

When I found that the theory I had matched the data I thought it was all sorted, until I started to look at data for certain cameras that didn't fit the pattern - for instance:

ZWO 290M - ratio about 0.488 +/- 0.006 (but Altair 290M I get readings of ~0.29)

Prototype 294C - ratio about 0.480 +/- 0.007 (I have two sets of data for ZWO 294 cameras, one is ~0.288, one is ~0.48)

Where I get two different ratios for a particular sensor, it's the read noise that differs between the two, not the e/ADU value. There are some other ratios that come out of some sensors, but they are rare, whilst the 0.288 and ~0.48 seem more common.

My problem is that I don't understand the 0.48 value - what causes the read noise at 8 bit for those cameras to behave differently (the readings at 12 bit are very similar). Where does this figure of 0.48 come from?

The read noise is measured by taking two short dark frames, subtracting one from the other - which removes any fixed pattern noise - and then calculating the standard deviation of the subtracted data and dividing by sqrt(2) to account for the fact that two frames contribute noise to the subtracted data. This is a standard approach to measuring the read noise - all it requires is for the sensor to actually be in the dark. If the sensor still has some light on it, then it would give a higher read noise, but not a consistent value of 0.48 across many measurements and not just for 8 bit measurements...

Anyway, I'm stumped on this for the moment - which makes it harder for me to ship pre-recorded sensor data with SharpCap as I would need measurements at both 8 bit and 12 (12/14/16) bit depths, rather than just getting the high bit depth measurement and calculating the 8 bit one. Any thoughts on what is going on would be most welcome!

cheers,

Robin

I thought I understood how astro cameras worked in 8 bit mode and how I could generate a set of sensor analysis figures for 8 bit mode from those measured in a higher bit depth (ie 12 bit). The idea I had went like this...

The most important features of 8 bit mode (compared to 12 bit mode) are

* The ADU value is reduced to the range 0..255 from 0..4095 (by dividing by 16). This means the e/ADU figure is actually 16 times bigger for the same gain

* The read noise in 8 bit mode is dominated by inaccuracies caused by rounding when you divide the ADU by 16 in the first step above - for instance if the light level would give you a 12 bit adu of 3241, you get 202.5625 when dividing by 16, rounded to 203, an error of 0.4375

The second observation about read noise lets you predict the read noise for a camera in 8 bit mode - basically you assume that all the pixels that give you a readout of 203 really should have values ranging between 202.5 and 203.5 and assume an even distribution in that range. You can calculate the standard deviation of a uniform distribution of width 1, and it turns out to be 1/sqrt(12), or about 0.288.

This value of 0.288 shows up in the measurement of many sensors in 8 bit mode - basically it is the ratio between the read noise and the e/ADU gain, for instance an Altair 183C at minimum gain in 8 bit mode has Read Noise=18.13, e/ADU=62.96, which gives a ratio of 18.13/62.96 = 0.288

When I found that the theory I had matched the data I thought it was all sorted, until I started to look at data for certain cameras that didn't fit the pattern - for instance:

ZWO 290M - ratio about 0.488 +/- 0.006 (but Altair 290M I get readings of ~0.29)

Prototype 294C - ratio about 0.480 +/- 0.007 (I have two sets of data for ZWO 294 cameras, one is ~0.288, one is ~0.48)

Where I get two different ratios for a particular sensor, it's the read noise that differs between the two, not the e/ADU value. There are some other ratios that come out of some sensors, but they are rare, whilst the 0.288 and ~0.48 seem more common.

My problem is that I don't understand the 0.48 value - what causes the read noise at 8 bit for those cameras to behave differently (the readings at 12 bit are very similar). Where does this figure of 0.48 come from?

The read noise is measured by taking two short dark frames, subtracting one from the other - which removes any fixed pattern noise - and then calculating the standard deviation of the subtracted data and dividing by sqrt(2) to account for the fact that two frames contribute noise to the subtracted data. This is a standard approach to measuring the read noise - all it requires is for the sensor to actually be in the dark. If the sensor still has some light on it, then it would give a higher read noise, but not a consistent value of 0.48 across many measurements and not just for 8 bit measurements...

Anyway, I'm stumped on this for the moment - which makes it harder for me to ship pre-recorded sensor data with SharpCap as I would need measurements at both 8 bit and 12 (12/14/16) bit depths, rather than just getting the high bit depth measurement and calculating the 8 bit one. Any thoughts on what is going on would be most welcome!

cheers,

Robin