CMOS for photometry

The 'CMOS Slug' being tested.

Articles in this series:

Characterising RTS (this page)

RTS Pixel Behaviour

Dark Frames

Linearity

Binning

On-sky Photometry


 

I have now taken delivery of a QHY183M camera which will replace the SBIG ST-8XME (the Bowers Beetle) loaned to me by Craig Bowers after my long-serving ST-8XME (the Audacious Ant ) died last Sept.  Long live the CMOS Slug!

This is a bit of a step into the unknown.  While there is lots of astrophotography online with CMOS sensors, there is very little information on high precision photometry.  There is some on-going discussion on AAVSO forum, and a new paper here on the use of sCMOS for Sky Survey applications, but little specific consideration of how the quirks of CMOS will affect ppt (parts per thousand) level bright star photometry, such as for exoplanet transits.

The ultimate purpose of my testing is to understand what the main issues might be and to work out fixes, if necessary.  I will get around to the issues of linearity and read/dark noise that are familiar to users of CCDs, but I will start with characterising RTS (Random Telegraphic Signal).  This manifests as pixels going bright and dark at random even in the absence of light.  For a technical discussion of how RTS originates in the sensor, see this.  CCDs do not behave this way.

This is work in progress, and the direction it takes will depend on what I find.  The first step is to see if there is a problem.

 

How the tests were done

Images were acquired using Sequence Generator Pro, with the sensor at -5 C.  I have not yet done any testing at different temperatures, so this is not the final decision on observing temperature.

CMOS cameras generally come with user selectable Gain and Offset.  I have selected Gain=0 in order to fully use the maximum well depth of 15,500 e-.  I have not confirmed this, but just going by the number published by QHY.  The choice of Offset=8 is to just avoid clipping of low values in bias frames.

The frames produced were analysed using small Python programs I wrote.

 

Distribution of noise

Here is a histogram of a typical bias frame.  Strictly speaking this is a very short exposure (0.001s) dark, rather than a bias.  I’ve done this because there are reports that bias frames taken with zero exposure do not behave as you would expect, with 0s bias having higher ADUs than short exposure darks – see this.

 

Typical bias frame histogram

Note that the y-axis is the log of the number of pixels.  I’ve done this so that any outlier pixels will be apparent even if there are only a few.  The x-axis is the ADU output from the camera divided by 16.  The sensor ADC is actually only 12 bits  (0-4095), but this is mapped to a 16 bit value by effectively multiplying by 16.  Not a big problem, but for brevity, I’ll refer to ADU/16 as just ‘ADU’.

By itself, this plot takes only so far.  Yes, there are some points that stray quite far from a normal distribution where almost no points would be outside of +/-4 sigma (standard deviation).  In fact the kurtosis of 4.2 tells us that the wings of the distribution are wider than in a normal distribution (which would have kurtosis = 3.0).  But the outliers could be because of a fixed pattern with some pixels always brighter/dimmer than others.  These could then be subtracted out through normal image calibration.

In order to cancel out the effect of any fixed pattern, I subtract one bias frame from another.  For each test I acquired 200 bias frames, then paired them off at random and did this subtraction for each pair.

 

Bias frame subtracted from another.

The wide wings of the distribution are not due to a subtractable fixed pattern.  There are thousands of pixels that don’t behave in a gaussian way.  Granted that this sensor has 20 million pixels, so even 10,000 suspect pixels are only 0.05%, but again, this is not how CCDs behave.  For comparison, below is the same plot from a ST-8XME (the Beetle).

CCD biases subtracted.

This is almost perfectly gaussian, as indicated by the upturned parabola, and the kurtosis close to 3.0.  There are no points outside of +/- 6 sigma.  But see how wide the distribution is.  There is a 100 ADU range, whereas the CMOS ADUs have a range of <50.  From the sigmas, QHY183M read noise =  1.0/SQRT(2)*GAIN = 2.6e-  (GAIN = 3.7 e-/ADU), and ST-8XME read noise = 10.8/SQRT(2)*2.7 = 20.6e-.

The CMOS read noise is an order of magnitude less than my current CCD.  So perhaps the shape of the noise distribution does not matter for photometry.

That depends, though on how these outlier pixels behave frame by frame.  If they just have large scatter, the effect would just be like a higher read noise.  And do bad pixels continue to be bad pixels?  Perhaps the random noise could happen to any of the 20m pixels in the sensor.  That would reduce the impact on photometry, but also make the problem harder to fix.

 

Outlier pixel behaviour

From subtraction of each bias pair, I identified every pixel with deviation greater than 10 sigma.  The 10-sigma figure was chosen to limit the number of pixels identified from each frame to the 100’s.  I counted the number of times each pixel was outside of the 10-sigma limits in each of the 100 frame subtractions, and used that to sort the resulting list of suspect pixels.  I got a list of nearly 9,500 pixels.  The ADU level in each of the 200 bias frames of the worst of these pixels was then plotted.

Some example of RTS affected pixels:

RTS Pixel Example 1
RTS Pixel Example 2

 

 

RTS Pixel Example 3

There seems to be 3 distinct levels of ADU.  The central one of ADU = 30 is the offset or ‘pedestal’ level corresponding to no signal.  But there are alternative levels 10 above and below.  Example 3 may look a bit different, but follows the same pattern, just with greater scatter around each of the 3 levels.

Below is an example of the least bad pixels of this set of 9,500.

 

RTS Pixel (less severe) Example 4

There are still 3 levels, but this time the alternative levels are about 4 ADU above and below.

Here’s my non-electronics engineer explanation of the origin of RTS.  The physical pixels in the sensor are read twice in a process known as Correlated Double Sampling, in order to cancel out any offset value.  The discrete levels happen when a stray electrons are emitted in between the 2 reads.

 

What questions have been answered?

  1.  Does the IMX183 sensor have RTS?  Yes.
  2.  Are the bad pixels identifiable in that specific pixels continue to switch levels in subsequent frames?   Yes.  In my case I identified 9,500 pixels, but I could have increased this number by tightening the 10-sigma range.
  3. Will the bad pixels subtract out from the science frames, leaving a clean signal?  I don’t think so, but this does need to be checked.  Science frames will be dark subtracted so it depends on how these pixels behave in a longer dark exposure.  Do the jumps up and down scale up as dark signal accumulates?

This is the subject of the next test, on RTS pixel behaviour.