II Weight formula?

[mschuster]

Is the formula ImageIntegration uses for Weight documented? I could be mistaken but it appears in my integrations to be some function of at least Scale Factors and Noise Estimates (when using Scale + Offset and NoiseEvaluation).

Thanks,
Mike

[mschuster]

No reply so I used Mathematica to search for a best numerical fit to data logged in the console. Here is the result:

Let sr and nr be the scale factor and noise estimate for the reference sub.
Let st and nt be the scale factor and noise estimate for the target sub.

The target sub's weight is ((sr * nr) / (st * nt))^2.

The residuals are very small so IMO it is likely that this is the correct formula.

I could very well be mistaken here, but my wild guess on the motivation for this formulation:

A sub with smaller noise (measured by the multi-resolution support algorithm) is weighted higher in the integration. A sub taken in darker conditions will have less sky flux shot noise and hence its SNR in all regions will be higher, hence its higher weight.

A sub with larger dispersion (measured by the MAD function) is weighted higher in the integration. A sub taken in more transparent conditions (less atmospheric extinction, less air pollution) will have proportionally increased flux in all regions and hence its SNR in all regions will be higher, hence its higher weight.

I don't yet have a guess as to why the power of 2. It may be any power would work, with larger values increasing the resulting weight dispersion.

Thanks,
Mike

[georg.viehoever]

Mike,

I am not sure about your result. The formula you gave would give the reference image a weight unequal to 1. The idea of weighting by 1/variance=1/stdev^2 is probably still behind it, see http://en.wikipedia.org/wiki/Linear_least_squares_(mathematics)#Weighted_linear_least_squares .

Georg

[mschuster]

Georg, I think it's OK, since for the reference sr = st and nr = nt so weight is 1. The n's appear equal to those of the NoiseEvaluation script. The s's are ratios of the MAD's of the reference and target (this is documented). Your idea for the 2 makes sense.

Thanks,
Mike

[georg.viehoever]

Mike, you are correct. The reference image would get a 1. I did not see the () as they are... I am getting old
Georg

[Juan Conejero]

Hi Mike,

Sorry for the delay in answering to your post. Well, you already have answered to your own question using very smart methods 

Indeed, ImageIntegration's image weighting function for the ith image is:

w_i = (n_i * s_i)^-2

where n_i are noise estimates and s_i are scaling factors:

s_i = ADev( I₀ )/ADev( I_i )

and ADev( I ) is the average absolute deviation from the median computed for all pixels of image I (excluding pixels outside the ]0,0.98] range), used here as a robust estimate of dispersion. By convention, the first image in the integration list (denoted here with a zero subindex) is the reference image for weighting purposes. The quadratic shape of the weighting function attempts to account for the fact that the signal-to-noise ratio is proportional to the square of the signal. We have had some controversy in the PTeam around the way we are squaring scaled noise estimates. Personally I think that the function we are using is correct for a model where we can express an image as:

I_i = B_i + k_i*(S + n_i)

where B_i is a background zero offset, S is the deterministic signal and k_i is a scaling factor. We can compute each B_i in a robust way as the median of all significant pixels. Note that all additive pedestals B_i are automatically excluded from the weighting function: (1) in the computation of scaling factors because ADev() measures variability from the median, and (2) in the computation of noise estimates because the multiscale noise evaluation algorithm calculates unbiased noise estimates from wavelet difference coefficients, which have zero mean on each wavelet layer.

[mschuster]

Hi Juan, thank you.

Some feedback: StarAlignment's interpolation typically reduces the MRSNoise values of my registered subs by a what is effectively a random amount. The variance of this reduction is large, possibly due to the fact that my subs are undersampled. This reduction does not represent a true increase in SNR, so to use these MRSNoise values for weighting purposes is a mistake in my opinion. What I do instead is run ImageIntegration on my calibrated but unregistered subs just for the purpose of noting their weights. I record these weights as FITs keywords and use them when integrating the registered subs. It seems to me this is a more accurate way of accounting for relative SNR.

Thanks,
Mike

[Juan Conejero]

Hi Mike,

This reduction does not represent a true increase in SNR, so to use these MRSNoise values for weighting purposes is a mistake in my opinion.

I completely agree with you. The problem is that pixel interpolation, which is necessary to register the images, acts like a low-pass filter. The registration reference image is not interpolated, which leads to comparatively higher noise estimates, and this in turn leads to lower weights for integration. The practical consequences of this signal loss are not significant for large integration sets, but they can be more serious for small sets. One way to avoid this problem is to register all the images against a synthetic star field. Another way, more tricky, is to apply a very slight noise reduction to the registration reference image (usually with wavelets). Anyway this is a deficiency that has to be removed from our tool chain.

We are aware of this problem, and it will be fixed in the next versions of the ImageCalibration, StarAlignment and ImageIntegration tools. We'll do just what you are doing now, but it will work in a completely automatic fashion. ImageCalibration and StarAlignment will compute (as an option) noise estimates (SA before image registration), which will be stored as special FITS keywords. The estimates will be calculated if the corresponding keywords are not present. ImageIntegration will use these keywords, if they are present, to retrieve noise estimates. If the keywords don't exist, noise estimates will be computed as usual.

Thank you for pointing out this problem, and also for your insights to resolve it. By the way, what keyword names are you using to store noise estimates?

[Harry page]

Hi

Oh so much out of my depth am I     

Harry

[mschuster]

Thank you Juan, your plan sounds great. I am using IWEIGHT.
Mike

[mschuster]

Harry, maybe this will help. :-)

Here is a plot showing calibrated but unregistered weights for subs captured on five nights from a dark site. Subs were 40 min H-a. All five nights were affected by smoke from a forest fire, the smoke was worse on the first two nights, and worst on the last sub of the first night. They were taken tracking across the meridian on all of the nights, with the third sub on each night nearest to the meridian. I think these weights captured my subjective feeling for conditions very well.



Here is a plot showing weights for the registered subs generated by StarAlignment. You can see more noise in this data. My guess is the noise is a result of the interpolation process, as a function of variations in the alignment matrix (ie, small changes in subpixel positioning due to dithering, along with maybe a slight bit of scaling and rotation noise from the star alignment process itself). These weights don't reflect my sense of the conditions nearly as well as those above.



My subs are undersampled and have good focus and star shape (4.2"/pixel, less than 1.1 pixel FWHM Moffat4, less than 0.38 eccentricity). Interpolation across these sharp stars varies a lot with subpixel positioning. I think this accounts for the amount of noise. Using the calibrated but unregistered weights instead solves the problem.

I hope this helps,
Mike

[georg.viehoever]

Mike,
I think part of this problem may be related to this http://pixinsight.com/forum/index.php?topic=3320.msg22928#msg22928. Interesting measurements!
Georg

[Juan Conejero]

Hi Mike,

This is a very interesting experiment. The fluctuations that you have detected in the second graph are due to the interpolations applied to register the images. Small rotations and subpixel shifts among exposures inevitably generate aliasing artifacts that modify the original noise distribution in the raw images, especially for undersampled images. Georg did some interesting tests to evaluate the effects of different interpolations which are worth to mention. They can be seen in the thread he has linked above.

[Harry page]

Hi

Thanks for the explanation  8)  I understand know

Harry

[mschuster]

Hi Juan,

Just to double check, your post above says the rejection scale factor is the average deviation ratio, but the II documentation says it is the median deviation ratio.

Also, the II documentation recommends not scaling when integrating lights, but I think the batch script does in fact scale.

Thoughts?

Thanks,
Mike