Exposure Calculator

Fri May 19 19:44:04 BST 2023

Hey Joseph,

Dr. Glover's presentation was not wrong in any way at all -- it was all
factual, empirical stuff that we can all agree on.

On the other hand, I think it was incomplete. He ends his presentation by
saying that there's a point where shorter subs start to significantly hurt
you, while longer subs provide almost no benefit. Speaking strictly from an
SNR perspective, he's right, but he fails to mention any of the
practical downsides of short exposures.

On the one hand, very short exposures are great. You can eliminate small
passing clouds, moments of atmospheric turbulence, wind gusts that jiggle
the telescope, etc. in the most surgical way, eliminating only the smallest
amount of bad data. In the limit, shooting shorter and shorter subs is
called "lucky imaging," and it's frequently used with planetary observation.

There is a huge downside to taking a billion 1 second exposures, though --
you'll fill up your storage, and your computer will melt, but you'll
probably achieve essentially the same result as you would with a more
modest number of 2 or 5 minute exposures.

There are also workflow considerations. It's much easier to build a dark
and bias library for a small number of standard exposure durations, instead
of painstakingly customizing darks and bias frames for every target and sky
condition.

For typical astrophotographers in urban and suburban environments with
modern low-noise cameras, it's true that subs longer than 5-10 seconds
cease to provide any real benefit in terms of SNR, but there are typically
more urgent practical considerations, e.g. the size of your datasets and
the time required to process them.

You could say that we are lucky to live in a time where hobbyist cameras
are so good that 5 second exposures are sufficient to swamp the read noise.
That doesn't mean we should shoot 5 second exposures -- it means we should
luxuriate in the flexibility we now have to choose exposure durations of
almost any length which suits our workflow, our weather conditions, and our
mount and guiding capabilities.

On Fri, May 19, 2023 at 10:42 AM joseph.mcgee at sbcglobal.net <
joseph.mcgee at sbcglobal.net> wrote:

> Thanks for the feedback Warren,
>
> I'm a little unclear on your concern about the usefulness of the
> calculator.  But a large part of Dr Glover's presentations seems to be
> directed to getting astro-photographers to consider using shorter
> sub-exposures and larger stacks.
>
> If you believe this to be incorrect, or less than "optimal", maybe we can
> work together to come up with an alternate user-selectable calculation
> model that can be added to this tool.  I would just need this to be
> described in such a way that I can implement.
>
> I'd also be curious to see if folks would run this calculator to compare
> their experiences.
>
> Here's a process that might be helpful to determine the value of the
> calculator.
>
> Pick one of your images, or just a channel used in an image that you
> consider to be good quality.
>
> Set up the calculator with equipment, the conditions and the gain setting
> that you used for the imaging.
>
> Try to adjust the noise increase % so that calculator exposure time is
> close to the sub-exposure that you used for the image. (It might be tough
> to get a perfect match, close is good enough).
>
> How where did the noise increase % value end up?  Very far from the
> default 5%?
>
> Look at the stack grid to find the closest exposure count to what you used
> in the stack.  What is the Ratio on that line?
>
> ---
>
> So here's a long description and details from my learning experience a few
> years ago that lead to my research into sub-exposure calculations.  (Keep
> in mind that I still consider myself to be very much a novice in this
> hobby.)
>
> As I was first learning in my backyard using a one shot color ASI-071MC,
> with an f/5.5 refractor. (I typically set the camera gain at 50). I tried
> imaging at the 3 to 4 minute exposure times that I saw recommended on
> forums.  The results were awful, and very noisy.  I then purchased both a
> multi-band filter (Optolong l-Enhance for nebulae) and a light pollution
> filter (Optolong l-Pro for galaxies). But even after weeks of trial and
> error, I found that using the l-Pro filter for example, I still had to
> reduce my exposure times to about 60 seconds with no moon, and about 30
> seconds with a 1/2 moon.  In these conditions, to get an image that I
> considered acceptable required about 6 hours for the stack.
>
> There's a darker site in the mountains about 90 minutes drive from my
> home. I only make that trip around a new moon.  My trial and error process
> there included exposures up to 10 minutes, but even at 5 to 6 minute subs
> there was excess noise.  I settled on exposures that were 3 to 4 minutes;
> and I could get a result that was good enough to show to my friends and
> family, on a stack with just 2 to 3 hours of imaging.
>
> This experience triggered the research which lead me to Dr Glover's
> presentations. I used Dr Glover's equations initially on spreadsheet and
> later in a Java app. The sub-exposure time from those computations matched
> my experience fairly closely.
>
> I've since measured the SQM in my backyard on a new moon night as 19.3,
> and about 18.5 with a half moon.  So lets look at what the calculation says
> for these conditions using the l-Pro filter (I estimate that the l-Pro is
> passing about 165nm), and I'm leaving the noise increase % at the default
> 5% recommended by Dr Glover:
>
> In my backyard with a new moon, the calculated exposure is 69 seconds;
> just slightly higher than the 60 seconds I found with trial and error in
> these conditions.
>
> Back then I was still employed with limited available time, so I had been
> limiting my stacks to what I could get in a single night.  With 6 hours of
> imaging the calculator shows a ratio (quality) of about 80.  That a ratio
> of 80 was good enough for me to share with my friends and family.  But in
> looking at the stacking data I see that the quality is still climbing well;
> going to a 7th hour would improve the quality by 8%, that might have have
> been worth doing.
>
> But at some point we have to weigh the cost in time vs benefits of longer
> stacks.  The quality improvement at 20 to 21 hours is not so great; the
> gain in quality would only be 2.4% for that added hour, and it would be a
> stack of nearly 1100 images.
> Then with a half-moon in my backyard: the calculated exposure matches the
> 30 seconds that I found I needed with trial and error. But to be honest I
> was never able to get a very good galaxy image around a half-moon from my
> backyard.  But now it's clear from the calculator that I would need about
> 14 hours in these conditions to reach a ratio of just 80.
>
>
>
> Now at the darker site near my home, (I've not yet measured the SQM at
> this site, but a light pollution map says it is 20.5):
>
> The calculation shows a sub-exposure of 221 seconds, that is right in the
> middle of the 3 to 4 minute range I found with trial and error.  And with
> just 3 hours stacking the ratio (quality) shows 101.   I was really happy
> with images from that site with just 3 hours of stacking.
>
> So let's run one more calculation for a very dark sky, SQM 21.96 right on
> the margin of Bortle 1 & 2.
>
> I have not yet experienced such a site, so I cannot make any comments
> about the calculator's result. But it is showing an optimal sub-exposure of
> about 14 minutes. It also shows that a stack of just 1 hour, (5 exposures),
> would easily exceed the quality that I find acceptable to share with my
> friends and family.
>
> I also think it's very interesting to see that quality improvement of
> adding just a second hour in these conditions; a 34% improvement in quality
> to go from 1 to 2 hours of imaging in these conditions!  But the
> diminishing improvements of larger stack are still evident; at the 20 to 21
> hour time-frame the quality improvement is only 2.2%, (but that is at a
> ratio of over 500, so it mat not be possible to recognize any noise in this
> image).
>
>
> On 5/18/23 13:28, Warren wrote:
>
> I think a fundamental problem with this approach is that it tells you the
> *minimum* acceptable exposure duration, which is long enough for some other
> noise source (likely skyglow) to greatly exceed your sensor’s read noise.
>
> This is useful information, but mostly when you’re shooting from a Bortle
> 1-2, where your sensor’s read noise is potentially the limiting noise
> source — where 60 minute narrowband subs make sense.
>
> For folks in urban and suburban environments, with modern low-noise
> cameras, any realistic exposure duration (e.g. 60-300 seconds) is
> sufficient for skyglow shot noise to greatly exceed sensor read noise.
>
> On Wed, May 17, 2023 at 10:55 PM Hy Murveit <murveit at gmail.com> 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:
>> [image: 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/20230519/50e2cedc/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Pjpyvh0ISGXKukA8.png
Type: image/png
Size: 68866 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kstars-devel/attachments/20230519/50e2cedc/attachment-0005.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: daKPnBwkHtfgkkrh.png
Type: image/png
Size: 69807 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kstars-devel/attachments/20230519/50e2cedc/attachment-0006.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: C02t5KPn6YbqnqKb.png
Type: image/png
Size: 69767 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kstars-devel/attachments/20230519/50e2cedc/attachment-0007.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: FEkmtmRA05lDU0en.png
Type: image/png
Size: 68910 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kstars-devel/attachments/20230519/50e2cedc/attachment-0008.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/20230519/50e2cedc/attachment-0009.png>