Optimal Exposure and Noise Calculator

Hy Murveit murveit at gmail.com
Sat Mar 4 19:52:33 GMT 2023


I've told Joeseph I'm happy to help him out and mentor him on KStars code,
should he want to go forward with this project.

All that said, I'm going to be a "party pooper", but just this one time,
and say that I personally don't understand the need for exposure
calculators. They definitely used to be needed in the old days with large
read-noise CCD cameras, but in the modern era with low read noise, I'd
guess this is rarely an important calculation anymore.  Probably issues
like guiding, disk usage, saturation of stars dominate issues like read
noise and once you have a reasonable tradeoff figured out, which is likely
the same tradeoff as your friends use, you rarely need to change it.

Please feel free to disagree, I have never tried to optimize my exposure
time--Somehow, long ago I wound up using 4 minutes for RGB & Narrowband at
gain 0.5 adu/e- for RGB, and gain 1.0 adu/e- Narrowband.  I use 2 minutes
for L at 0.5 adu/e- so I don't saturate too many stars. If I were shooting
brighter stars I guess I'd use shorter exposures. ZWO ASI1600 mm pro.

Hy


On Sat, Mar 4, 2023 at 11:20 AM Warren <warren.craddock at gmail.com> wrote:

> Hey all, I believe you can directly measure read noise from a series of
> bias frames, which are taken at the shortest possible exposure duration.
> That eliminates dark current and photon shot noise, leaving only the read
> noise.
>
> I don’t think it’s necessary to make a database of popular cameras. :)
>
> On Sat, Mar 4, 2023 at 10:16 AM joseph.mcgee at sbcglobal.net <
> joseph.mcgee at sbcglobal.net> wrote:
>
>> Hi Jasem,
>>
>> I don't believe that we would be able to measure (or distinguish) the
>> read noise from an image. My understanding of read noise is that it is
>> introduced during the process where the analog to digital converter is
>> reading the pixel values on the sensor when the exposure is completed and
>> the data is being prepared in a buffer for transmission over the USB
>> connection.
>>
>> I'd used a graph from the ZWO website for the gain to read noise values
>> on my camera.  But I just looked at the QHY website and see some similar
>> graphs. The QHY graph is actually more detailed than what I've seen on ZWO
>> site.
>>
>> So it would be a bit tedious to transcribe these values from the graphs
>> for every possible camera.  Maybe I can contact ZWO and QHY to see if they
>> will provide raw data for their cameras.
>>
>>
>> On 3/4/23 09:19, Jasem Mutlaq wrote:
>>
>> Hello Joseph,
>>
>> You can use QtCreator which is easier for UI Qt designs. But you can use
>> any IDE you feel comfortable with. Is the sensor gain to read noise ratio
>> something that can be measured from FITS Viewer by perhaps capturing a few
>> imagers with different gains + exposure values?
>>
>> --
>> Best Regards,
>> Jasem Mutlaq
>>
>>
>>
>> On Sat, Mar 4, 2023 at 8:01 PM joseph.mcgee at sbcglobal.net <
>> joseph.mcgee at sbcglobal.net> wrote:
>>
>>> Thank you Jasem,
>>>
>>> I have not yet setup a dev environment for KStars; I normally use
>>> Eclipse, but I will install one of the recommended IDEs. For most of the
>>> last 20 years of my career I was developing middle tier code, no recent
>>> user interface work. So I'll need to ramp back up on UI development.  A few
>>> folks have offered to mentor me on integrating this into KStars.  So I'll
>>> get rolling on this shortly.
>>>
>>> I did not realize that I could get SQM from Indi/Ekos, that solves a big
>>> concern for me!
>>>
>>> There is another dependency for the calculation. My code has a small
>>> reference table that relates the imaging sensor gain value to a sensor read
>>> noise value. I've only built one table so far; for my ZWO ASI-071. So I'll
>>> need to work on building tables for other cameras, (but it might be better
>>> if I built a curve-fitted functions for this because the tables limit the
>>> gain selection to specific values).
>>>
>>> Would you happen to have list of the most commonly used cameras?
>>>
>>>
>>>
>>> On 3/4/23 00:12, Jasem Mutlaq wrote:
>>>
>>> Hello Joseph,
>>>
>>> This would be an *outstanding* feature to add to KStars! Thank you for
>>> working on it. It would require an interface and also proper
>>> integration with the rest of KStars & INDI infrastructure, for example, the
>>> filters used..etc.
>>>
>>> Would this be better suited for FITS Viewer integration?
>>>
>>> SQM & F-Ratios can be retrieved from INDI/Ekos, we probably need to add
>>> a field for the filter band-pass in the equipment manager.
>>>
>>> Do you have a development environment ready as per the instructions in
>>> KStars Gitlab? https://invent.kde.org/education/kstars
>>>
>>> --
>>> Best Regards,
>>> Jasem Mutlaq
>>>
>>>
>>>
>>> On Fri, Mar 3, 2023 at 8:16 PM joseph.mcgee at sbcglobal.net <
>>> joseph.mcgee at sbcglobal.net> wrote:
>>>
>>>> Hi All,
>>>>
>>>> I'm a retired software developer (mostly Java, C, and some C++).  I've
>>>> been using KStars on a Raspberry Pi (Ubuntu), since I got interested in AP,
>>>> (around 2020).  Back in late 2021 I wrote an optimal exposure time
>>>> calculator (in Java), based on the work of Dr Glover.  I just got to
>>>> thinking that it might be a nice addition to KStars, and today I found a
>>>> request for it:
>>>> https://indilib.org/forum/wish-list/5300-exposure-calulator.html?start=12
>>>>
>>>> My current code is pretty simple but has no user interface.  It uses a
>>>> few classes for configuration, a table of sensor gain to read noise,
>>>> observation site location SQM value, optics F ratio data, and
>>>> (experimentally) a filter bandpass table.  The code just iterates through
>>>> all the combinations of the inputs to output tab delimited data to the
>>>> console, that I copy into a spreadsheet.
>>>>
>>>> Keep in mind that the exposure time calculations are optimal (per Dr
>>>> Glover), but not necessarily practical.  I've seen a slow optic, with a
>>>> filter, in very dark skies,  produce a optimal sub exposure time
>>>> calculation that exceeded 3 hours.
>>>>
>>>> If this were integrated into KStars, we would obviously need to provide
>>>> a means for a user to input some of their own configuration information.
>>>>
>>>> Please let me know if you'd like to consider integrating this into
>>>> KStars, (I would need coaching/help if I were to take this on).
>>>>
>>>> Example output:
>>>>
>>>> I have my code configured for the read noise for my main imaging
>>>> camera, (a ZWO ASI-071 Color), SQM data for four observation sites.  F
>>>> ratios for four optics, and bandpass info for two filters.  And I'm using
>>>> an allowable noise increase of 5%.
>>>>
>>>> A small section of the output provides this information for a given
>>>> site, optic, and sensor gain selection:
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> *Site Name:*
>>>>
>>>> Chuchupate
>>>>
>>>>
>>>> *Sky Quality:*
>>>>
>>>> 21.65
>>>>
>>>> magnitude per arc-second2
>>>>
>>>> *Light Pollution Base Rate:*
>>>>
>>>> 19.6
>>>>
>>>> e per second
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> *Optic Name:*
>>>>
>>>> Esprit 100
>>>>
>>>>
>>>> *Light Pollution Rate:*
>>>>
>>>> 0.65
>>>>
>>>> e per second for f/5.5 optic
>>>>
>>>>
>>>>
>>>> *Camera Sensor Gain:*
>>>>
>>>> 50
>>>>
>>>> *Read Noise:*
>>>>
>>>> 2.78
>>>>
>>>>
>>>>
>>>> *Filter*
>>>>
>>>> *Optimal Sub-exposure (sec)*
>>>>
>>>> *Shot pollution electrons*
>>>>
>>>> *Exposure shot noise*
>>>>
>>>> *Exposure total noise*
>>>>
>>>> No Filter
>>>>
>>>> 349.1
>>>>
>>>> 226.2
>>>>
>>>> 15
>>>>
>>>> 15.3
>>>>
>>>> Optolong l-Pro
>>>>
>>>> 634.8
>>>>
>>>> 411.3
>>>>
>>>> 20.3
>>>>
>>>> 20.5
>>>>
>>>> Optolong l-Enhance
>>>>
>>>> 3174
>>>>
>>>> 2056.3
>>>>
>>>> 45.3
>>>>
>>>> 45.4
>>>>
>>>> And accumulated data for imaging sessions of 1 to 5 hours:
>>>>
>>>>
>>>>
>>>> *3,600.00 seconds*
>>>>
>>>> *7,200.00 seconds*
>>>>
>>>> *10,800.00 seconds*
>>>>
>>>> *14,400.00 seconds*
>>>>
>>>> *18,000.00 seconds*
>>>>
>>>> *Filter*
>>>>
>>>> *Exposure Count*
>>>>
>>>> *Stack Total Time*
>>>>
>>>> *Stack total noise*
>>>>
>>>> *Exposure Count*
>>>>
>>>> *Stack Total Time*
>>>>
>>>> *Stack total noise*
>>>>
>>>> *Exposure Count*
>>>>
>>>> *Stack Total Time*
>>>>
>>>> *Stack total noise*
>>>>
>>>> *Exposure Count*
>>>>
>>>> *Stack Total Time*
>>>>
>>>> *Stack total noise*
>>>>
>>>> *Exposure Count*
>>>>
>>>> *Stack Total Time*
>>>>
>>>> *Stack total noise*
>>>>
>>>> No Filter
>>>>
>>>> 10
>>>>
>>>> 3491.44
>>>>
>>>> 48.37
>>>>
>>>> 21
>>>>
>>>> 7332.03
>>>>
>>>> 70.09
>>>>
>>>> 31
>>>>
>>>> 10823.47
>>>>
>>>> 85.16
>>>>
>>>> 41
>>>>
>>>> 14314.92
>>>>
>>>> 97.93
>>>>
>>>> 52
>>>>
>>>> 18155.51
>>>>
>>>> 110.29
>>>>
>>>> Optolong l-Pro
>>>>
>>>> 6
>>>>
>>>> 3808.85
>>>>
>>>> 50.14
>>>>
>>>> 11
>>>>
>>>> 6982.89
>>>>
>>>> 67.89
>>>>
>>>> 17
>>>>
>>>> 10791.73
>>>>
>>>> 84.4
>>>>
>>>> 23
>>>>
>>>> 14600.58
>>>>
>>>> 98.17
>>>>
>>>> 28
>>>>
>>>> 17774.62
>>>>
>>>> 108.31
>>>>
>>>> Optolong l-Enhance
>>>>
>>>> 1
>>>>
>>>> 3174.04
>>>>
>>>> 45.43
>>>>
>>>> 2
>>>>
>>>> 6348.08
>>>>
>>>> 64.25
>>>>
>>>> 3
>>>>
>>>> 9522.12
>>>>
>>>> 78.69
>>>>
>>>> 5
>>>>
>>>> 15870.2
>>>>
>>>> 101.59
>>>>
>>>> 6
>>>>
>>>> 19044.24
>>>>
>>>> 111.29
>>>>
>>>>
>>>>
>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kstars-devel/attachments/20230304/327f5939/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ooDv8C0XDGbpvFZq.png
Type: image/png
Size: 238280 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kstars-devel/attachments/20230304/327f5939/attachment-0001.png>


More information about the Kstars-devel mailing list