New "sensor analysis" tool in CCDciel program

[han59]

In the latest beta version of CCDCiel under menu tools there is a new menu called "sensor analysis" where you can test your camera sensor for read noise, linearity and some other parameters. This is not for everyone but if you like to verify the reported values of your camera you could try. It only requires a flat panel or substitute and will take 15 minutes or less.

Feedback is welcome.

Han

Download latest beta version of CCDCiel:
https://vega.ap-i.net/tmp/ccdciel/

Documentation:
https://www.ap-i.net/ccdciel/en/documentation/sensor_analysis

Edited July 28, 2023 by han59

[han59]

An updated CCDCiel has been released. The sensor analysis tool has been improved to cope with "random telegraph noise" (RTN), also called salt & pepper noise. This is what is measured using my ToupTek IMX571 camera (ATRC3CMOS26000KMA):

 

The read noise for the HCG mode at gain 100 is reported to be around 1 e-. However if you measure the actual noise it is higher around 1.6 -e. This is caused by "random telegraph noise". This manifest itself as flickering hot pixels. It is clearly visible if you calculate the difference between two darks or bias frames. Several hot pixels will be visible because they are flickering and are not removed by subtraction. Only if you measure the noise using a sigma clip routine you get the pure read noise. Mathematical as follows:

read noise including RTN := stdev(bias1-bias2)/sqrt(2)

read noise excluding RTN := stdev2(bias1-bias2)/sqrt(2)  where stdev2 is using a sigma clipping to remove hot pixels.

 

This is also visible in the total noise  which is defined as sqrt(sqr(read(noise)+sqr(RTN)+dark_current):

 

There is almost no RTN in my ASI1600 camera:

 

An other thing noticed while testing the ToupTek IMX571 is the charge persistence (cmos image lag). It is wise to remove the first dark since it has a higher median/average value then the following darks.

The bars indicate the median dark pixel values. This dark series is taken directly after a flat. If the first bar is higher then the second bar (both are for the same camera gain) then the camera is having some charge persistence. So there is some charge left from the previous flat image. The height & values of the other bars can be influenced by the gain setting.

 

There is no charge persistence in the ASI1600 since the first bar has the same value as the second bar:

[ONIKKINEN]

Will test my ATR3CMOS26000KPA and see what the test spits out, curious to see the results especially the things sharpcap sensor analysis did not report.

Re: charge persistence, its a noticeable issue in certain circumstances such as taking flats with a preset exposure time where the first exposure is flooded, or darks like you mentioned. With automatic flat tools (NINA flats wizard) its not an issue since the tool takes test exposures first. Also an issue for a first light in a sequence after some idling (such as post meridian flip if not platesolving which exposes once or twice). Already knew it existed but good to have a number on it.

Regarding the read noise thing, what implications would this have for an imager? Should i treat the camera like it had 1.6e RN instead of the simple measurement of 1e?

[han59]

4 hours ago, ONIKKINEN said:

Regarding the read noise thing, what implications would this have for an imager? Should i treat the camera like it had 1.6e RN instead of the simple measurement of 1e?

I don't think you can do much with it. It only indicates that things are not so ideal as it looks. The main problem is that these pixels look like faint stars and not like noise. I still have to do an experiment if stacking removes them effectively. E.g if you stack twice 20 darks and calculate the difference between the two stacks then hopefully these RTN is gone.  The the same will happen for 20 lights corrected with 20 darks.

 

Edited August 2, 2023 by han59

[ONIKKINEN]

Had some issues running the analysis, i think it has something to do with the chosen automatic exposures being clipped/too bright for the blue pixels in my OSC camera (flat panel is quite blue, not a problem normally). I mean the analysis itself was very straight forward and completed just fine, but the results are not in agreement with sharpcap or manufacturer graphs.

Example of one of the exposures i managed to get a snapshot of. Loads of them were clipped for the right most peak which i presume is the blue channel.

And the results, which i think may not be too valid if the test exposures were clipped:

Linearity clearly hits a wall (presumably because of the clipped blues), read noise is also much higher than what sharpcap or the manufacturer report. I expected results very similar to yours, but i think this test did not complete properly.

I think the desired exposure level could use some adjustment for cases where there are several peaks like with OSC cameras and non-neutral flat panels (most of the cheap ones), relaxing it to 60% or 50% might yield much better results, or allowing the user to select the median target.

[ONIKKINEN]

Actually, disregard the read noise thing, i had low noise mode off when loading the ASCOM driver. I also did a little MacGyvering of my flat panel by adding painters tape and some printer paper to tweak the panel to be a bit more neutral. The exposures are still clipping for higher gains, so no cigar yet. Needs some tweaking for OSC cameras for sure.

Also, on another test run i ran into an issue with the tool being unable to find a suitable exposure, even though it was sitting at 70% which is exactly what it requests.

[han59]

Yes OSC camera requires an other strategy.  If I remember well SharpCap is using only the green channel. Probably the best approach will be to separate the raw OSC pixels in Red, Green1, Green2, Blue or  Red, (Green1+Green2)/2, Blue sensitive pixels. Creating four or three graphs is not a problem. Then a blueish or reddish flat panel does not effect the measurement. I will work on that.

I did a test with my ToupTek darks. A stack of 9 darks of 300 seconds show clearly hot pixels. A difference between two dark stacks seems to remove hot pixels reasonable. So darks are still essential in the image processing.

An other thing which can be reported is the amount of hot pixels or RTN pixels. According this report 2% of the IMX571 pixels are effected by RTN (random telegraph noise).

Han

 

A stack of 9 darks of 300 seconds exposure:

 

The difference of two stacks of 9 darks of 300 seconds exposure:

 

 

 

 

 

[han59]

The linearity test of OSC cameras should now work better using the latest nightly build:

Index of /tmp/ccdciel (ap-i.net)

In case of an OSC camera it uses only the green sensitive pixels for the linearity test.  The idea of testing the red and blue channel was abandoned because it made the code too messy.

It would be nice if it can be tested.

The program also reports the percentage of pixels suffering from RTN (Random Telegraph Noise). When I test my ASI1600 I get about 0.18% RTN but for the ToupTek IMX571 camera it reports more then one percent of the pixels suffering from RTN.  It is pretty independent of the exposure time. Next step could be to report the RTN flux. But that requires more testing to understand the behaviour. 

Han

 

Edited August 5, 2023 by han59

[ONIKKINEN]

Ran another test:

Worked well this time with regards to the exposures and linearity. I ran the dark current test this time and noticed something which may not be intended. The first 10 times it took the test exposure it came up with an error of something along the lines of "could not get fullwell from driver". Did not think to take a snapshot of this but it was something like that. The next 10 exposures were without this error, so was it intended for this test to run twice or did it run twice because of the error in getting the fullwell from the driver the first 10 times?

Another thing to note is that the e-/adu, Read noise, and full well values reported by the test are all around 30% extra from what sharpcap and the RisingCam site itself report (actually they removed this info at some point so no longer reports anything) as the values so maybe something needs a tweak still. Or could be that the other tests are wrong, anyway i am not educated enough on that to say yay or nay but your mono version reports numbers what i would have expected so maybe this is some OSC camera issue still.

[han59]

For my mono version ToupTek IMX571 sensor camera, I measure a read noise of 1.086 e- at minus 10 degrees Celsius sensor temperature.

I assume you get a little higher reading due to the sensor temperature introducing some extra noise. Could you try is at a lower sensor temperature?

 

The full well difference is strange.

It is calculated as follows:

 FullWell_capacity[e-]:=sat_level[adu]*gain[e-/adu]

The sat_level is 65535 so it is due to the gain which in your case is 0.335 e-/adu.

This gain is calculated as follows:

σ_light[adu]:=STDEV(light1-light2)/sqrt(2)

gain[e-/adu]:=flux[adu]/sqr( σ_light[adu]) (formula 3) 

It has probably something to do with the Bayer matrix. Can you share two flats made with your camera at gain 100 and a low temperature which I could analyse?

Han

 

 

 

Edited August 7, 2023 by han59

[ONIKKINEN]

4 hours ago, han59 said:

For my mono version ToupTek IMX571 sensor camera, I measure a read noise of 1.086 e- at minus 10 degrees Celsius sensor temperature.

I assume you get a little higher reading due to the sensor temperature introducing some extra noise. Could you try is at a lower sensor temperature?

 

The full well difference is strange.

It is calculated as follows:

 FullWell_capacity[e-]:=sat_level[adu]*gain[e-/adu]

The sat_level is 65535 so it is due to the gain which in your case is 0.335 e-/adu.

This gain is calculated as follows:

σ_light[adu]:=STDEV(light1-light2)/sqrt(2)

gain[e-/adu]:=flux[adu]/sqr( σ_light[adu]) (formula 3) 

It has probably something to do with the Bayer matrix. Can you share two flats made with your camera at gain 100 and a low temperature which I could analyse?

Han

 

 

 

Here are 2 flats from my most recent session:

 

 

Dark current at +5 shouldn't cause a jump so high in noise levels with the camera since it is so low to begin with but maybe since that is different between our runs. I will run it at a cooler temperature next to make sure this is not causing issues. For the rest of the issues it would be enough for the gain to be calculated incorrectly to also get the wrong read noise and full well values since those are derivative values. I already knew that the camera has little bit less than 1e read noise and around 16.5k full well capacity at gain 100 with HCG and low noise mode on so very similar to your mono measurements.

Edited August 7, 2023 by ONIKKINEN

[ONIKKINEN]

Regarding those flats, something came to my mind just now. I have had doubts whether the old version of NINA and the Touptek driver in it engages the low noise mode since there is no toggle for it. So if there is something odd about those flats, that would probably be it.

So might not be the most useful test subject.

[han59]

Thanks. I got the flats. You could delete them to save space on this forum.

The flat show a typical unbalance between the colours. Green is about 38000 adu, blue is 30000 adu and red only 15000 adu.  Did you use an electro-luminance panel for these flats?

I'm pretty sure if the standard deviation calculation uses only the green pixels then  the measurement for gain, full well capacity and read noise will be more in line. I will work on it.

Han

 

[han59]

Okay, I have created a fix and uploaded the new CCDCiel executable to my own webpage:

www.hnsky.org/ccdciel.zip

You have to extract the executable and then move it to C:\Program Files\CCDciel

A version with an installer will probably come tomorrow. https://vega.ap-i.net/tmp/ccdciel/  That is done by Patrick.

Tell me if this works.

Han

 

[ONIKKINEN]

Flat panel is a plastic toy 25€ drawing tracing panel lit by LED strips behind a dew diffusion layers. Far from ideal but all channels calibrate well despite the dodgy levels so have not thought about that further.

I will run another test later today, or tomorrow if i dont have the time. Got an idea, will run the test with another OSC camera (ASI 678MC) to see if there are similar issues and we can rule out some funny business with drivers as an issue.

[han59]

No problem. The installer is now updated.

Index of /tmp/ccdciel (ap-i.net)

Han

 

[ONIKKINEN]

This version seems to have done the trick with more familiar numbers for e-/adu and full well. Not seen a full well test go over 16.7k on mine yet, and usually gain 100 reports closer to 0.25 but this is pretty close to what i assumed to see. Ran it cooler this time, but i dont think this would affect the measurements greatly when dark current is still fractions of an electron per minute.

Just because i was curious, i ran the test with my 678MC too and it worked well without anything special to note. As general feedback i do like how you have allowed testing only specific gain values, like what i did here to get a more accurate readout around the point where the camera goes into HCG mode (i believe 182). Interesting to see that the random telegraph noise is almost absent with this one.

[han59]

Thanks for the feedback. 

I noted again that the linearity test finds a great offset at zero exposure. I see the same in my test. This requires further investigation. You could argue that changing the exposure time is not ideal. The light source intensity should be adjusted.  Maybe a led should be used as light source and the voltage and current recorded assuming the efficiency is constant which it is probably not. But then the test would involve more into a lab test then a simple test.

Han