Sensor Measurement Feature - Read Noise

A place to report problems and bugs in SharpCap
Forum rules


If you have a problem or question, please check the FAQ to see if it already has an answer : https://www.sharpcap.co.uk/sharpcap-faqs

Please also read about Troubleshooting USB Issues before posting.

*** Please do not post license keys - please report any problems with licensing to 'admin' by private message ***

Please include the following details in any bug report:

* Version of SharpCap
* Camera and other hardware being user
* Operating system version
* Contents of the SharpCap log after the problem has occurred.
[If SharpCap crashes, please send the bug report when prompted instead of including the log]
Post Reply
Fossil Light
Posts: 6
Joined: Wed Dec 23, 2020 9:02 am

Sensor Measurement Feature - Read Noise

#1

Post by Fossil Light »

Hi Robin,
I am doing some work on understanding noise in planetary imaging which will end up as a webpage for my website www.SkyInspector.co.uk. I want to explore the importance of read noise in planetary imaging for different planetary subjects such as Uranus/Neptune, Mars, Saturn, Moon, Nightside of Venus etc.

Part of this study is to measure the read noise of some common planetary imaging cameras and the sensor measurement feature in SharpCap came in really handy for this. I love the data it provides such as the true gain in e-/ADU but I have some issues on read noise measurement and wonder if might be able to help me or offer comment.

I have tabulated some read noise data below which illustrates my issues.

-I get good agreement for ZWO cameras between ZWO data and the EMVA1288 sensor measurement data at 0 gain from camera companies like FLIR and Lucid.
-I get good agreement for ZWO cameras between the ZWO data and the SharpCap sensor data at 16bit
-I get poor agreement between FLIR/Lucid data and SharpCap data for the Chameleon 3 with the IMX265 chip with SharpCap seemingly undermeasuring noise. Any ideas why this camera doesn't play ball with the read noise measurement.
-I get a big difference between the read noise measured at 16bit and 8bit and seemingly much too high a read noise value at low gain and 8bit mode. Any idea why this might be?


EMVA 1288 data SharpCap measure
Camera Chip Gain FLIR Lucid ZWO data 16bit 8bit


ASI174MM IMX174 0.0dB 6.8e¯ 6.0e¯ 6.5e¯ 38.9e¯
ASI174MM IMX174 30dB 3.6e¯ 3.8e¯ 4.1e¯

ASI290MM IMX290 0.0dB 3.5e¯ 3.3e¯ 16.5e¯
ASI290MM IMX290 30dB 1.0e¯ 1.1e¯ 1.4e¯

ASI224MC IMX224 0.0dB 3.1e¯ 3.0e¯ 21.5e¯
ASI224MC IMX224 30dB 0.8e¯ 0.8e¯ 1.2e¯

CS3 IMX265 0.0dB 2.3e¯ 2.1e¯ - 0.8e¯ 12.6e¯
CS3 IMX265 30dB - 0.8e¯ 0.7e¯

ASI462 2.5e¯ 2.6e¯ 13.3e¯
ASI462 0.6e¯ 0.8e¯ 0.9e¯

ASI178 IMX178 0.0dB 2.4e¯ 2.2e¯
ASI178 IMX178 30dB 1.4e¯


Many thanks
Martin
User avatar
admin
Site Admin
Posts: 13122
Joined: Sat Feb 11, 2017 3:52 pm
Location: Vale of the White Horse, UK
Contact:

Re: Sensor Measurement Feature - Read Noise

#2

Post by admin »

Hi Martin,

first the easy bit - 8 bit read noise.

At minimum gain, in 8 bit mode, sensors tend to have a very large e/ADU figure - for instance for the 174 sensor, this value is about 132e/ADU.

If you consider the definition of the read noise to be root_mean_square(measured electrons - actual electrons), and you remember that the measured electrons can only vary in multipled of 132, you can see that the bulk of the high read noise is actually a result of rounding the pixel value to the nearest 8 bit ADU value.

You could argue that this isn't strictly read noise from an electrical point of view, but it has exactly the same effect on image quality, so it's easiest to count it as read noise. It's a good reason not to capture deep sky images in 8 bit.

Once you apply a decent amount of gain (say 30dB which is rougly 30x gain), the e/ADU has dropped down to a much more reasonable 4e/ADU, so the effect of truncating the data to 8 bit becomes much smaller.

Of course, if you are imaging bright targets and can get the bulk of your image most of the way up towards the FWD of the camera (~32000e), the shot noise of ~170e will far exceed the read noise of ~38e, even at minimum gain in 8 bit (which is why we don't gain from using high bit depths for imaging bright objects).

Now, the 265...

I don't think I've actually had a camera with a 265 sensor here to play with, so no experience to bring into play.

SharpCap measures the read noise by taking pairs of dark frames at minimum exposure, which should be identical if it wasn't for the read noise. The difference between those frames is then evaluated (to remove any constant offset) and the remaining signal is measured then divided by sqrt(2) to get the read noise (each frame contributes 1*read noise, but they add in quadrature, so the difference has sqrt(2)* read noise).

Anything that performs any sort of lossy compression on the image data will break this measurement technique - compression routines will happily change noisy but nearly uniform blackness into much more uniform blackness... There could be other reasons, but that was the first thing that came to mind.

Robin
Fossil Light
Posts: 6
Joined: Wed Dec 23, 2020 9:02 am

Re: Sensor Measurement Feature - Read Noise

#3

Post by Fossil Light »

Thanks so much Robin for your time to reply to my mail and to go into so much really useful detail about read noise.

Although important for deep sky imaging the subject of read noise is rarely discussed amongst planetary imagers. However, with more unusual and difficult targets like imaging detail on Uranus and Neptune, methane imaging of Jupiter and Saturn, and IR imaging the night side of Venus, I believe read noise can start to become significant compared to the shot noise. This is what I am exploring at the moment so for me understanding how the read noise value is generated for different gains in Sharpcap sensor measurement feature is really important.

Thanks again for your time let me digest fully what you have said before I respond further.

Regards,
Martin
Post Reply