Astrophotography Notes: ISO, Light Pollution, Histograms

ISO

I, like many people, thought that lower ISO means less noise. However this isn't true, at least not for modern camera. As a first order approximation, my understanding is that the signal path looks something like this:

1. Photons impact the sensor
   
2. Sensor generates electrical signal
   
3. ISO amplifier amplifies the signal
   
4. Readout electronics converts the signal into digital numbers
5. digital numbers recorded as a RAW file

Generally speaking there are two major source of noise:

1. Random noise inherent in the photons arriving at the sensor
2. Noise generated by readout electronics and quantisation noise in the ADC
1. aka readout-noise 

We can express the signal-to-noise ration (SNR) of the RAW image as follows:

RAW_SNR = (ISO_gain * S) / (ISO_gain * N + N_readout)

Where S and N is the light signal and noise, and N_readout is the readout-noise. ISO_gain is the gain  corresponding to the ISO value, but not the ISO value itself. e.g. ISO 100 doesn't not mean gain of 100.

Generally speaking S >> N, that is the light signal itself has good SNR. 

In low light situations where S of a similar magnitude to N_readout, if we use a low ISO such that ISO_gain is 1, then 

RAW_SNR ~= S / N_readout

as N_readout >> N. 

By increasing the ISO such (ISO_gain * N) >> N_readout,

RAW_SNR = (ISO_gain * S) / (ISO_gain * N + N_readout) 

 ~= (ISO_gain * S) / (ISO_gain * N) 

~= S / N

That is, we approximately recover the original SNR of the signal which is the best that can be asked for without additional processing.

This bears out in practice. I took a series of images in low light with the same aperture and shutter speed, changing only the ISO. Each image was then digitally processed in darktable with exposure compensation so images are of the same brightness (i.e. 1 extra step of exposure for each reduction in ISO):

The improvement in image quality at ISO 6400 compared to ISO 400 is significant. 

Light Pollution

With such high ISO, when I take pictures in my backyard in Bortle 7 skies, I get images that appear overexposed due to the high background brightness:

Single exposure, high background brightness

Histogram, plenty of room.

Previously I have viewed such images as "unusable". However upon looking at the histogram, it is clear that despite the background brightness, the majority of the signal is properly captured without clipping. Indeed, when post-processed in sirl, the final image does not suffer from the background glow:

So be not afraid of using high ISO in light polluted skies - as long as the histogram is not clipping the signal is there and can be recovered.

GDK/GTK Signal Handling Notes

 I recently tried my hands at implementing motion event support for canvas widgets in Toga on Linux, which uses GTK3 as its GUI back end. In the process I had learn to navigate GDK's event handling mechanics and documentation. This post is a summary of notes I made during the process.

Basics

GTK widgets general signals, which you can be notified of if you connect() to the widget by specifying

1. the name of the signal
   
2. callback to invoke when the event occurs

Event Names

To find out what signals a widget emits you naturally look at the widget's documentation, e.g. for DrawingArea. However you will quickly realise not all signals are listed. The list does not include signals such as "draw" which is mentioned in python-gtk-3's documentation. The actual list of inherited signals can only be seen in the documentation for Widget. Why the disparity? No idea.

Event Mask

Not that widgets do not emit all possible signals, there is an EventMask bitfield that determines which signals a widget will emit. It is not enough to simply connect() to a signal - you must also enable those events you wish to receive if not enabled by default via gtk_widget_add_event(). Note that the relationship between signal names defined and the event-mask required is not explicitly defined. It comes down to guessing the how they are related and trial and error.

Verifying GoTo Mount Settings

I recently got a iOptron SmartEQ Pro+ mount and while setting it up I was confused over the time. Should it be local time and then I set the UTC offset in minutes? What do I do with the DST setting?

One way I found of checking whether my settings is correct is

1. Look up the altitude and azimuth coordinates of a bright star like Sirius using a planetarium app
2. Command the mount to slew to that star
3. On arrival the altitude and azimuth coordinates are displayed on the handset
4. Compare the coordinates shown on the handset vs coordinates obtained in step (1). They should match to at least the degree. If not the time and location setting is wrong.
5. Tweak settings and repeat from (2) onwards until there is at least degree level agreement between the mount and reference altitude and azimuth coordinates.