Exposure Calculator

Thu May 18 10:46:23 BST 2023

Hello Hy,

I was planning on working on edits to the handbook but I recently became 
obsessed with trying to build a camera sensor analyzer to help determine 
read-noise values for cameras that do not include it in the manufacturer 
documentation the way that ZWO and QHY cameras do.

But I've attached a pdf that is a rough draft of docs for the 
calculator, (not really complete yet, and some of it is now incorrect 
due to some design changes), so the attached doc probably won't fully 
answer all of your questions.

Yes, the filter bandwidth is nm.  So 300 is essentially luminance, RGB 
would be roughly 100, etc.

To help clarify, during my research on this exposure calculator topic I 
came across a forum post with a chart.  The photographer in this case 
indicated that he was imaging in Bortle 5.5 skies, *but with a f/3.0 
optic*, he provided the following chart for his exposures:

So you can see that his luminance exposure times with a gain of 0 with a 
Moravian C3 camera were just 13 seconds, (but he is only running 561 
exposures).   When he runs with a gain of 2800 (which is beyond a 
step-down in read-noise on his camera), the luminance exposure time 
drops all the way down to 2 seconds.

His RGB exposures at gain 0, are just 39 seconds with 187 exposures per 
channel.  He doesn't get into "long-ish" exposures until he is running 
narrow-band.

That would lead us to your 2nd point.  The stack time is merely the 
product of the exposure time & number of exposures. This would be 
analogous to the "signal". Stack noise represents the total noise in the 
stack, but keep in mind that noise is reduced in proportion to square 
root of the number of images.  The ratio column represents ratio of 
stack time to noise.  So think of ratio as being a simple measure of 
"quality" for the stacked image.  But my docs do not elaborate on a 
reasonable value for the ratio.  My understanding from posts about Dr 
Glover's calculations are that a ratio greater than 80 would be 
considered extremely good, and a ratio of 100 is excellent.

I was giving some thought altering the calculator grid display to make 
it graphical. Perhaps allowing a user to select a desired ratio, and the 
calculator simple would display a small chart to better show whether the 
curve is reaching a point of diminishing returns for an increase in 
stack time.

In your example I think that the calculation is showing that a planned 
stack time of 20 hours may be a bit excessive; and that your are 
basically onto the part of the curve where there is very diminishing 
returns for the increase in stack size.  You could achieve a ratio of 
100 on these 12 second luminance exposures with just 12 hours of exposures.

But also consider that running the gain lower, maybe even at 0 might be 
reasonable in this case.   The exposure times would rise into the 30 
second range and with the lower gain, the dynamic range on the image 
should improve.  Also be aware that the "noise increase" value can be 
adjusted, 5% is recommended default. In my opinion lowering the "noise 
increase" might make sense in your case.

Also, in the chart from the forum post, the column listed for "Noise 
Tolerance Factor C" is inversely related to the "noise increase" control 
in this calculator.  The Factor C value of 25 on his chart is a noise 
increase of 2%, the Factor C value of 10 on the chart is a noise 
increase of 5% .  Given that that calculator provided you with a 
exposure time that seems "short", you could afford to reduce the Noise 
Increase %.

So, if you were to change to a 1% noise increase, and lowered the gain 
to 0, the exposure time would rise to 170 seconds, and as a result 11 
hours of imaging, 232 exposures would produce a ratio of 100 in the 
stacked image.

And with regard to the excess precision on the UI, I agree I went a bit 
extreme on decimal places. But as I was testing I was frequently trying 
to match the calculator results with data I found on images posted in 
forums. In some cases to match up those values I needed the extra 
precision.  I can certainly reduce the precision in a future release.

One more comment... multiple instances of the calculator can be run 
concurrently to allow for easy side-by-side comparisons with alternate 
inputs.

On 5/17/23 22:54, Hy Murveit wrote:
> Joseph,
>
> Thanks so much for getting the exposure calculator up and running in 
> KStars. Impressive accomplishment!
>
> I just tried using it, and have some questions/comments I was hoping 
> you could address.
>
> Here's a screenshot, with questions below:
> Screenshot 2023-05-17 at 10.13.06 PM.png
>
>   * I think I filled in the boxes appropriately above, though not
>     sure, please let me know. I tried these values: sky quality 19
>     (about what I've measured at my house), f/8 reflector, full
>     bandwidth (300nm), my ZWO ASI1600mm camera at gain 75 (I assume it
>     wants the gain I use for the 1600, but I tried other values too),
>     20 total hours of exposure time desired, default noise increase of
>     5%. It seems to be telling me to take 5956 images each 12.09
>     seconds long, which is obviously not a good answer. Am I doing
>     something wrong?
>   * Not sure what Stack Time, Stack Noise, and Ratio mean. Are shot
>     noise and total noise in electrons? (Need tooltips to help)
>   * I was able to get it to give me a reasonable exposure time (e.g.
>     about a 2-minutes) if I set Noise Increase % to 0.4, but I really
>     didn't know what to put in there, and so used the default was 5%.
>     Do you know, is 5% a good default for the noise increase? Can we
>     give more guidance on what noise increase people should start with?
>   * The tool needs better tooltips for pretty much each value that
>     needs to be entered.  Most  tooltips say "An implementation of Dr
>     Robin Glover's exposure calculation." We can give credit elsewhere
>     (e.g. usually done in "About KStars"), but the tooltips should be
>     informative. For instance, is gain the actual gain values one
>     enters for the camera, or do you mean something like quantum
>     efficiency? Assuming it's the value entered to the camera's
>     driver, you should say that "Gain value used for your camera".
>     Filter Bandwidth should include units (e.g. nm in this case.).
>   * Don't need 3 decimal places for Sky Quality (make it one or two
>     decimals). Ditto for focal ratio.
>   * Is there some documentation on use somewhere? E.g. can a section
>     be added to the handbook? Also, please start a forum thread
>     describing this new tool and how you recommend users use it.
>
> Thanks again,
> Hy
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kstars-devel/attachments/20230518/eacf7083/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: zNbeMMFgE0HXj6KE.png
Type: image/png
Size: 42688 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kstars-devel/attachments/20230518/eacf7083/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screenshot 2023-05-17 at 10.13.06 PM.png
Type: image/png
Size: 378407 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kstars-devel/attachments/20230518/eacf7083/attachment-0003.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: HelpManualDraft.pdf
Type: application/pdf
Size: 344071 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kstars-devel/attachments/20230518/eacf7083/attachment-0001.pdf>