Signal-to-noise

[Ignacio]

Hi,

What is the correct way of estimating signal-to-noise ratio, say, if one wants to compare two different methods of calibration/stacking?

I am familiar with the tools for estimating noise, but the signal side clearly needs some kind of scaling/normalization if one would just compare noise levels.

The same goes for the weighting of subs during integration. When the noise estimate is selected as the weight, I often see that the less obvious subs get the higher weights. For instance, when background levels are high.

thanks,
Ignacio

[mschuster]

Try using AvgDev from the Statistics process as signal for your signal to noise ratio. This will give an estimate assuming that the frames are observations of the same target (dithering and flipping OK) and the background gradients are similar (big gradient differences will invalidate the results). Doing this ignores poisson noise, but even so it is reasonable thing to do IMO. You can add in poisson noise estimates of course, but doing so tends to bias the results toward the bright objects in your frame. If dim object SNR is important, leave it out.

Integration weights are biased a bit now due to smoothing done by StarAlignment. Measure calibrated but unregistered frames.

Mike

[Ignacio]

Thanks for your response, Mike. Problem is, background levels are different, so some sort of scaling/normalization needed. Also, color calibration is not exactly the same (how the different channels are aligned and spread), and this also impacts the estimation of noise.

cheers
Ignacio

[mschuster]

Ignacio,

Using AvgDev as signal and MRSNoise as noise (from the NoiseEvaluation script) will well account for different background levels.

As background level increases (due to changes in sky background, light pollution, air glow, etc) the ratio AvgDev/MRSNoise will decrease. This indicates a loss of SNR. The primary change is in MRSNoise, which increases due to the increased noise in the brighter background.

As sky transparency decreases (due to haze, fog, clouds, dust, air pollution, increased atmospheric extinction, etc) the ratio will also decrease. Basically fewer photons make it through the muck and so SNR decreases. The primary change is a smaller AvgDev, which effectively indicates a loss of "contrast" in the frame.

The ratio AvgDev/MSRNoise is relative and not absolute SNR. As I mentioned before, when you compare the ratios of the frames, the comparison is valid only for frames of the same target. Also, as I mentioned before, the comparison is invalid if the frames have wildly different light pollution gradients.

If you use this ratio to compare frames with different exposure times, the one with the longer exposure will be the one with the larger ratio (assuming everything else stays the same). Both AvgDev and MSRNoise individually will be larger, but the increase in AvgDev will dominate. This indicates that the longer exposure has the larger SNR of course.

Regarding color, only compare like colored frames to one another (e.g. red to red). The ratio is completely invalid if you compare frames with different filters. But for the same filter the result should be helpful. It will distinguish the better frames from the worse ones.

This technique is only a rough rule of thumb of course. It is nice because it requires neither optical nor sensor parameters.

If you need something more, check out the HST operating manual. There is a ton of stuff on accurate characterization and measurements procedures there.

Thanks,
Mike

[Ignacio]

So what you are saying is that, thou not an absolute measure, it is a useful relative measure to sort a set of subs from a session. Is this what ImageIntegration uses for weighting factors?

Many thanks,
Ignacio

[mschuster]

Yes, not absolute, but useful just as you say for relative comparisons.

ImageIntegration weights approximately equal the square of this ratio divided (normalized) by the square of the ratio of the reference frame (i.e. the first frame in the integration).

ImageIntegration needs a measure of variance rather than standard deviation of noise to do maximum likelihood estimation, hence the squaring.

And approximately because ImageIntegration uses a tweaked version of AvgDev that ignores both saturated pixels and zero pixels. The latter so as not to be biased by the zero pixels introduced around the edges of a frame for registration purposes.

Mike

[Ignacio]

Understood. Thanks again. I noticed you output such estimate in the PSFEstimator, although there the terminology seems to be MedDev instead of AvgDev, right?

Ignacio

[mschuster]

Oh no, sorry about this. MedDev differs from AvgDev and PSFEstimator is wrong to use MedDev. I have not fixed this bug. However the new batch script does use AvgDev. So use the new script or get the number from Statistics. I apologize for this mess.
Mike

[Ignacio]

Noted, thanks.

Ignacio