Optimum Exposure time

[festoon]

Hello all,

Inspired by what Robin has done with Sharpcap and the python coding that @Martin Meredith posted last week considering peak SNR for different mono cameras - I've been working on a python code that determines the exposure time for an allowed pre-determined increase in total noise, compared to the situation if only one long sub was taken.

The program has camera constants such as QE, pixel size, dark current, and bandwifth of pixel (colour or mono). Telescope constants of aperture, central obstruction, and F ratio. Sky constant being sky brightness, the object you are trying to detect magnitude and FWHM. Also input is the total exposure time and allowed increase in noise for stack compared to a single long exposure.

Fell free to take a look at the code and delve into tthe details. the results track well what Robin published in his recent presentation (albeit this does not take into account dark current or object noise) https://onedrive.live.com/view.aspx?resid=8C8FC1CCC662B920!15845&ithint=file%2cpptx&authkey=!AFJ0lTBqEagivdI

For my setup, it shows quite nicely that for my ASI385MC CMOS with low read noise I can use low exposures (~6 seconds for a 5% increase in total noise), and for my Atik 414 this minumum time increases to 24 seconds for the same % increase in noise. However the Atik can detect fainter objects after the stack of stars at magnitude 20.69 compared to 20.36 for the CMOS.

Criticism will be welcomed - I hope this is (or eventually becomes) a useful script

optexposure.py

[vlaiv]

I had a brief look at the code, and this one confuses me:

photons_sec_m2 = 4 * (10 ** 10) / (2.5 ** mag_target)

I think you are trying to get photon count per meter squared on top of atmosphere from target of certain magnitude?

10**10 part I get, although I think more precise figure would be 0.88e6 photons/cm^2, but 1e6 is close enough. Part that I don't get is magnitude conversion

mag = -2.5 log_base10 (amplitude_ratio) =>

amplitude_ratio = 10**(mag / -2.5) (in python notation)

I don't get constant 4 at the beginning.

Sky flux should be calculated the same way - sky brightness in magnitudes per arc second squared. Inclusion of filter bandwidth is good approximate, but I don't get this expression:

sky_flux=3.837*(bandwidth/550)*((pixelsize*1e6/f_ratio)**2)*10**(0.4*(21.7-mag_sky))

Why is there 21.7? Magnitudes are calculated from 0 up. Truly dark skies are about mag 22 if you wanted to go that way.

Another question, do you take a star to be your object, or you are working with extended objects?

For stars - you have it right, amount of signal in one central pixel for 2d gaussian distribution is a good way to approximate it. But that does not matter for extended sources - for that you simply use regular magnitude per arc second squared, only account for pixel size expressed in arc seconds squared.

Some things that you might want to add:

1. Atmospheric extinction - depends on target alt (air mass), elevation above sea level and expected transparency. Here is a good guide for this:

https://www.skyandtelescope.com/astronomy-resources/transparency-and-atmospheric-extinction/

2. Optical losses in imaging train. One can have multiple reflective surfaces, with different reflection coefficient - like 94%, 97% and even 99% with dielectric coatings. AR Coatings on glass elements are about 99.5% transmission. All of that affects total light throughput - needs to be accounted for "clear aperture" (much like subtracting central obstruction).

3. Impact of calibration frames.

Let's say someone uses 16 calibration frames, or to be precise darks, while someone else uses 100 of them. Will there be difference?

Indeed it will! Let's observe two distinct cases:

1) no dithering, exceptional guiding, subs do not need shifts for alignment.

In this particular case, calibration with darks will result in whole stack being "polluted" by noise in master dark - in case of let's say 1.6e read noise and 0e dark current noise (short exposure, cooled camera, dark current is minimal), in 16 calibration frames case 0.4e of noise will be added to whole stack, while in 100 darks case - only 0.1e

2) full dithering - no two subs overlap and each need to be shifted.

In this case, calculation goes like this - each sub is "polluted" with additional noise from calibration master - in case of 16 darks this means 0.4e more noise per sub (added like regular noise addition to each sub), while in 100 darks it will be 0.1e per sub.

Moral of the story - use a lot of calibration files and dither

[Martin Meredith]

Hi Vlaiv

Regarding your first question, this comes directly from Raab's paper that I cited in the original post which in turn cites Berry and Burnell. If you read the Raab paper you'll see what assumptions he is making e.g. 400-800nm band etc. (which is where I'm assuming the factor of 4 comes from, combined with a Vega flux of near 1000 photons s- cm-2 Ang-1)

http://www.astronomy.ohio-state.edu/~martini/usefuldata.html

Here's a further discussion:

https://www.cloudynights.com/topic/536809-converting-surface-brightness-in-stellar-magnitudes-to-photon-flux/page-2

Martin

[vlaiv]

13 minutes ago, Martin Meredith said:

Hi Vlaiv

Regarding your first question, this comes directly from Raab's paper that I cited in the original post which in turn cites Berry and Burnell. If you read the Raab paper you'll see what assumptions he is making e.g. 400-800nm band etc. (which is where I'm assuming the factor of 4 comes from, combined with a Vega flux of near 1000 photons s- cm-2 Ang-1)

http://www.astronomy.ohio-state.edu/~martini/usefuldata.html

Here's a further discussion:

https://www.cloudynights.com/topic/536809-converting-surface-brightness-in-stellar-magnitudes-to-photon-flux/page-2

Martin

That is not what I find problematic, and we already discussed it here:

What I can't figure out is magnitude to ratio conversion used.

Python script uses following formula

photons_per_second_per_meter_squared = 0_mag_photon_count / 2.5^source_magnitude

Ratio relation to magnitude difference is as follows:

magnitude = -2.5 * log_base10 ( SourceIntensity / ZeroMagIntensity)

From this, we can easily see that we need

SourceIntensity / ZeroMagIntensity = 10^(magnitude / -2.5)

In original expression 2.5^magnitude is used instead.

We can check the difference by plugging in some numbers. Let's see how much photons are produced by 10mag source.

Python script will calculate it to be: 4*10e10 / 9536.74

Above formula will calculate it to be: 4*10e10 / 10000

For mag 20 source, difference is even bigger:

Python script will get ratio factor of:  ~90.949.470

Mag system will get it to be:  100.000.000

We can approximate above magnitude formula by substituting some values around like 10^(1/2.5 * mag) = (10^0.4)^mag, but in that case we get:

2.5118864315095801110850320677993^mag

rather than

2.5^mag and one should use more precision, like at least 2.512^mag as expression.

 

[vlaiv]

I think I answered my own question there

2.5 is just crude approximation to above formula.

[Martin Meredith]

Yes, Vlaiv, you're right and well spotted. I blindly implemented Raab's text (4 lines from base of p2 col 2) where 1 / 2.5^mag is used instead of 10^(-0.4 * mag). Since my code produced the same erroneous values as his I called it a day. 

Martin

[festoon]

Thank @vlaiv - your a top man!!!! And you've picked out the one bit of coding that I was unsure about

As @Martin Meredith points out the term below comes from the reference from Raab. --> we receive about 4E10 photons per second per square meter from a star of 0mag [3]. A difference of 1mag corresponds to a factor of 2.5 in the brightness.

photons_sec_m2 = 4 * (10 ** 10) / (2.5 ** mag_target)

In the cases shown here I take the object to be a star --> but I also put into code (currently commented out) a line if the object is a extended object.

For the sky brightness, am referencing the sharpcap tools page and I used the equation as he does to work out sky brightness to ensure agreement (from http://tools.sharpcap.co.uk/).

Also thank you for your suggestions, I'll start to incorporate them