astro imaging design spreadsheet (broadband)

[Shiraz]

Hi
Mike has agreed to put the attached spreadsheet in the "how to" section. In the meantime, would be grateful for any feedback.

the spreadsheet essentially puts most of the theory in one place - you can enter your environment, target brightness, telescope and camera characteristics and desired imaging time. It will tell you:
your sampling/resolution,
the expected FWHM at the focal plane,
the field of view,
the overall SNR performance with different sub lengths,
the optimum sub length,
the effective well depth after stacking and
the ADU value that you should see in the sky background of a sub.

It is a protected excel spreadsheet, but it also runs under openoffice. Best to unzip and scan it first and excel will query if you want to use a web sourced spreadsheet, so you will probably need to enable editing to get it to work. It has no macros and has been zipped for attachment through IIS. I use a fully up-to-date win10 system with the Microsoft security suite.

I have used the spreadsheet for a number of years and it has been spot-on for the two systems I designed with it. It allows different systems to be compared or any "what if" changes to an existing system to be assessed - before spending any money. It started life as a luminance-only version, but now also provides a rough estimate of performance with RGB filters. It is not really suitable for narrowband (better than nothing though) - am working on a NB version. I have tried to put in instructions and explanatory notes - are they sufficient?

the two attachments are an image of part of the main screen and the spreadsheet itself.

regards Ray

edit: just fixed a very minor issue in one cell - thanks for feedback

[Slawomir]

That's awesome, thank you Ray. I will wait for the NB version :)

[RickS]

Thanks for all the hard work, Ray! I'll be interested to have a dig through the details. I have a much simpler spreadsheet that I use for comparing performance of different scope/camera combinations.

Cheers,
Rick.

[Shiraz]

thanks Suavi. It isn't a major job and should be finished in the next few days - would be good to have it validated


Hi Rick - yep, a bit of effort went into it. Would be good to have a comparison with others.
Problem will be that other users will have to trust that there is no malicious software attached - there isn't any, but saying that really doesn't help :lol:. I kept it as "vanilla" as possible and I guess we all use other software from non-commercial sources, so perhaps there are precedents.

regards Ray

[markas]

Ray,

I have just run my current system through your spreadsheet with great interest, as I had done extensive work to dtermine optimum sub times for LRGB. System is: ASA10N at f/3.6; Moravian G3-16200; ASA DDM 85A unguided mount.

My theoretical work came up with 5 min as a safe optimum - and that any longer would be overkill. I determined it was better to do more subs to reduce calibration noise. (and dithering is very important in this)

Lo and behold, your spreadsheet comes up with the same answers that I got: above 3 min is generally OK, and 5 min is safe - ie on the flat portion of the S/N curve.

So from this initial look, I'm sold:thumbsup:

With many thanks,
Mark

[Shiraz]

:) that's a relief.

thanks very much Mark - really appreciate the feedback.

is it easy enough to use - any way to improve that you can suggest?

[rustigsmed]

hmmm looking about 1 to 2 mins for me.

got me thinking should the sky value change when using a light pollution filter like a cls ccd?

[Slawomir]

Hi Ray,

Just letting you know that I plugged in numbers to your spreadsheet to the best of my knowledge, and the graph confirms what I was getting before, that about 15-minute subs in my case are optimal and that there is minimal gain past that length. I guess sky brightness is the largest uncertainty for me, but with narrowband it should be comparable to an extremely dark site?

[clive milne]

Ray... someone should name a single malt whisky after you...

well done.
~c

[Shiraz]

Hi Russell. hadn't thought about CLS, but, since the filter will get rid of about half the bandwidth, set the filter to 150nm. The filter will also selectively attenuate the sky - not able to find any measurements, but suggest that you try making the sky about 1-2 mags darker as a first try.


thanks Suavi.
Sky brightness is a real pain, because the spectrum varies with location. Have finished the narrowband version, but need to validate it to make sure it is producing reasonable numbers for my location. Would be nice to have it checked elsewhere. Maybe will be fit to post tomorrow... In the meantime, just set the bandwidth to that of your filters if you want to try some narrowband ideas with the broadband model - it will not be very accurate, but is also not totally useless.


Hi Clive. Thanks very much for that. I will never have a malt named after me, but I have every intention of drinking a little bit over the next few years.

regards ray

[markas]

I have now spent some time looking at the spreadsheet, and I've tried a number of different systems. The all-important knee of the S/N vs sub time curve is consistently close to my calcs.

There is one issue:
The S/N results for stacked performance may be optimistic unless dithering is assumed. This is because with undithered subs, stacks are not re-sampled for registration. My understanding is that under these conditions calibration frame noise builds up with the number of subs, which may result in additional noise. If the number of subs is vastly lower than the number of subframes in the calibration frames, the noise increase is negligible. And of course if there is a large number of calibration subs, the noise from that source is low anyway.

I have not checked the maths myself, so I can't be definitive about it, but perhaps it is worth adding a note to the spreadsheet recommending dithering (and lots of calibration subs)?

Mark

[Shiraz]

that is spot on Mark.

The spreadsheet does not include fixed pattern noise. I assumed that it can be managed with proper processes (eg dithering and accurate calibration). However, you are right that the SNR predictions are "best possible" - they will be reduced if FPN is not managed. I will put in a comment to that effect.

My understanding is that the FPN does not actually build up - rather it does not reduce with integration like random noise does. If the same noise pattern is imprinted in all of the subs, it will be there in the stack as well. dither turns FPN into random noise and then longer integration can reduce that noise as well.

thanks very much for taking the time to test the spreadsheet.

regards Ray

[wasyoungonce]

Ray that's excellent...well done indeed! It'll be invaluable resource for users.

Brendan

[RobF]

Nice work Ray. Many thanks.

[Shiraz]

thanks Brendan, Rob. I really hope that it turns out to be useful to others. There are probably better ways to do this than a simple spreadsheet (particularly to ensure that input data is consistent). However, it is nice to be able to see everything on one page and to be able to check intermediate calculations at times. I would welcome any further suggestions on how to improve it.

regards Ray

[SamD]

Thanks Ray, the spreadsheet is nicely laid out. I've had a chance to compare it with some similar things I've done.

I think the read noise effect shown on row 48 is really useful. I’d often choose a 10% contribution, rather than 5%, so that I could use shorter sub lengths. I’d only have to increase the total number of subs a little to get the same stack SNR at the end.

Without trying to complicate things anymore, a few points that might be relevant:

1) Measuring Sky Brightness
Rather than enter the sky brightness in cell F7, I think it's more useful to derive it using the background sky level in each sub (net of bias). In fact, you can do this on your spreadsheet as it is by changing the Sky Brightness cell F7 so that the value in row 53 is equal to the background ADU count in subs (at the relevant sub length column).

2) Sky transparency - Celestial altitude of target
It might be helpful to change the Sky transparency in E10 to account for the celestial altitude of the target. Roughly:

Transparency = POWER(0.85, 1/COS(Target degrees from zenith) )

i.e. A star at the zenith has 0.85 its top of atmosphere intensity (at 525nm and at sea level), but the same star is only 0.72 its top of atmosphere intensity at an altitude of 30 degrees.

3) Stack SNR – Impact of resampling during alignment
In calculating final stack SNR, I use (roughly):

Total stack SNR = Sub SNR x SQRT(No of subs) x 1.5

The 1.5 is an extra factor to account for noise reduction during resampling (that happens when subs are aligned). I'll make a separate post to see what people's thoughts are on this. I haven't seen it mentioned elsewhere so I could be wrong - but it does seem to account for measured SNR in my stacks.

4) Mirror reflectivity – variation with colour
I measured my RC8 mirrors combined reflectivity to be 0.87 x 0.87 in green, pretty close to your typical 0.85 per mirror. There’s a significant variation with colour: 0.90 x 0.90 for blue; dropping to 0.82 x 0.82 in red; and around 0.80 x 0.80 for the Ha line). This means that with two mirrors, reflectors often only reflect 0.64 of the incident Ha, compared to refractors which generally transmit well at all wavelengths. Refractors beat reflectors in Ha !

[Shiraz]

thanks Sam.

by point:
1. I wanted a way to design a system before building something and having measured data - which is why it is that way around. Putting in measured data allows the model to be validated, but it requires that the physical system exist. However, comparing measured and calculated signal does provide a way to estimate sky brightness - its a pretty expensive SQM, but will add a comment to that effect.
2. agree in principle, but most imaging is done higher up and transparency is a guess anyway. seeing also has a similar falloff. Will add a comment pointing out that the model applies best high up
3. Great insight. the spreadsheet still provides valid SNR in the subs, but I will add a comment to the effect that what happens next (stacking and filtering etc.) can influence the final SNR and in particular that interpolation for stacking can significantly increase the SNR.
4. I deliberately kept the whole thing as a band-average model. Most of the calculations could be spectral, but my experience has been that band-average is good enough for this type of modelling. Thanks for the data on mirror reflectivity - hard to come by for real systems.

thanks for the thoughtful post - appreciated. regards Ray