A place to post guides, instructions and HOWTO documents on the use of SharpCap and Astrophotography in general

Forum rules
One tutorial per topic please.
Please only post content that you have created in this form.
Tutorials should be either in PDF format as an attachment or written in the first post of the topic. Links to video tutorials you created are also acceptable.

Brian, Yes the deep well is good; it is largely due to the large pixel size, which is also good for collecting more light.
For a real-life comparison of low-light CMOS cameras see https://www.1stvision.com/machine-visio ... amera.html

I asked FLIR about the high running temperature and they said: The temperature range from the specs is the environmental temperature range, not the temperature of the camera itself.
It doesn't help that the BlackFly is a very small, light enclosure. Adding fins and bolting it to my camera box as a heat sink helped. Alan.

Last edited by Hibou on Tue Jul 24, 2018 4:43 am, edited 3 times in total.

I have been trying to follow the calculation of dark current using the SharpCap method. As I understand it, you average the mean count per pixel (ADU) for four different exposure times, plot them and extrapolate to obtain the ADU for zero time (-> read noise) with the slope giving the ADU/second increase with time (-> dark noise). After dividing by a scale factor of 16 (?), you convert that to 0.38 e-/pixel/s at 20C by multiplying by e-/ADU, which depends on gain. Naive questions already:
1) Where do you find that number e-/ADU ? Is it 1.0 if I don't use gain ?
2) Where does the scale factor of 16 come from ?
3) Why is the mean count, extrapolated to zero exposure time, so high at 2500 ?

The AAVSO method you show on Excel sheet 2, is simpler, since you just subtract the mean ADU/pixel for short exposures (read noise) from the mean ADU/pixel for long exposures, and divide by the time (not done). The scale factor of 16 is again used. An even simpler subtraction method seems sufficient for a rough comparison of CCDs to CMOS.

The FLIR IMX249 CMOS gives 70 counts/pixel in 4s (max. exposure) and 64 for the minimum exposure with zero gain. (Yes, I switched time stamping of frames off). Then the dark current is of the order 1.5 e-/pixel/s i.e. (70-64)/4s at 45C.

In contrast my Lodestar ICX825 CCD gives 0.51 counts/pixel in 10s and effectively 0 for the minimum exposure, so dark current is of the order of 0.05 e-/pixel/s at ~25C. These numbers seem credible, given the known higher dark current for CMOS and the 45C operating temperature.

Looking at the noise, it has a large standard deviation, with isolated hot pixels for the longer exposures, and even for short CMOS exposures. The CMOS camera also has obvious amplifier glow on one side. Even if I do a double imageJ "despeckle" I can only get the apparent CMOS dark current down to 1.0 e-/pixel/s, more than an order of magnitude higher than the CCD.

So despecking isolated hot pixels and then binning 2x2 is more important for CMOS than for CCD, except for very short exposures.
But I haven't yet found how to implement FLIR's "Mode_7" capture in FlyCap, which is supposed to reduce noise and allow software binning.

1) Where does the e/ADU value come from? Perform a sensor analysis run on your camera (Tools->Sensor Analysis) and it will calculate the e/ADU value for a range of different gain values. Best to use one of the measured values, but youo can also interpolate between them

2) Again by running the sensor analysis you will find the bit depth of your sensor A->D converters (if you don't know it already). If you have a 12 bit range, then there are 4096 possible values (0..4095) but these are scaled up to the range 0..65520 to fill a 16 bit range by SharpCap, this scaling is the factor of 16. If you had a 10 bit ADC then the scale factor would be 64, for a 14 bit ADC it would be 4.

3) Why is the value at zero exposure so high? Most cameras have 'brightness', 'offset' or 'black level' control to adjust this (these are all effectively synonyms) - these controls simply add a constant offset to the pixel value of all pixels. It's usually good to adjust these so that the histogram peak from a dark frame is clear of the left hand side of the graph.

Regarding 3) Why is the value at zero exposure so high? I ran that test with a 'offset' value of 250 ADU counts. I could have chosen any value but it would not have affected the results.

The 'AAVSO method' was introduced to me in the 'CCD Photometry 1' course I took this past Spring. In my opinion Robin's method is more robust since it requires more data points. Under similar ambient temperature Robin's method yielded 0.384 e-/pix/s and the AAVSO method yielded 0.251 e-/pix/s. In my opinion I say that 0.384 is closest to the truth. The AAVSO method was taught to us in the context of "let's get a ballpark figure".

I did each analysis twice, and found similar results (which I am still thinking about, but I am initially impressed). Just two small comments.
1) The sequence light-field/dark-field/light-field presented a small practical problem in getting the light-field the same both times, but I guess that sequence is necessary ?
2) It should be possible to include the calculation of the dark current in the Sensor Analysis procedure ?

BTW, apparently "mode_7" capture with FlyCap, which reduces noise and allows software binning, is only available with FLIR GigE cameras, not USB-3

Thanks again to both Robin and Brian for these explanations. Alan.

the IMX249 figures look wrong - it looks like the e/ADU for zero gain got calculated incorrectly (too high) and everything is therefore off by some scale factor. I'm guessing it might be off by a factor of 16, since dividing all the e/ADU and noise levels by 16 would bring them down to sensible values.

I will have to test with my PGR cam to see if I see the same effect.

Ok, with my Blackfly I found that in 16 bit modes the high and low bytes of the image data were swapped (oops!). I'm sure it can't have been like that when I first wrote the code as I would have seen the rubbish picture and investigated, but never mind...

I have added code to flip the byte order back to the correct way round (let's hope the order change is consistent across all cameras) - this will be in the next 3.2 beta build.