Exposure Calculator
joseph.mcgee at sbcglobal.net
joseph.mcgee at sbcglobal.net
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>
More information about the Kstars-devel
mailing list