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.
I confirm that this is a mistake in the documentation. Initially the image scaling algorithm used MAD (median absolute deviation from the median) as a robust estimator of dispersion, but I changed it to AvgDev (average absolute deviation from the median) in one of the latest versions (I don't remember which one now and I don't have security backups at hand). I'll change the reference documentation as soon as possible to include up-to-date information.
The reason to prefer AvgDev instead of MAD in this case is that MAD rejects the tails of the sample distribution completely, while AvgDev does not. In the case of deep-sky raw images we always have a strong central tendency (a single and narrow main histogram peak). What we want to evaluate here is the true width of the mean peak of the histogram. The AvgDev is a better estimator of dispersion in this case, in my opinion, since it is more comprehensive with data that departs from the central peak. Take into account that we compute AvgDev
excluding all pixels outside the ]0,0.98] range, which rejects most outliers (black borders, hot pixels, cosmic rays, saturated stars, and the brightest pixels of plane and satellite trails) and hence robustifies the image scaling routine.
Although the current scheme based on AvgDev is very reliable and accurate, I don't discard the possibility of changing our image scaling function again in one of the next versions of the ImageIntegration tool, since it is an essential part of the pixel rejection process. Anyway, we currently are gearing towards more sophisticated pixel rejection algorithms, such as the multiscale image integration method described in
this tutorial.
Also, the II documentation recommends not scaling when integrating lights, but I think the batch script does in fact scale.
The BatchPreprocessing script applies the additive+scaling output normalization for integration of light frames, while the documentation recommends no scaling, which is also the default setting in the II tool. This is another incongruence with the documentation, but this time it is intentional.
My decision to use additive+scaling output normalization in the BPP script is based on the following reasoning. For a coherent data set, i.e. when all the integrated frames have very similar dispersion values, scaling has no practical effect because all scaling factors should be very similar. However, most data sets acquired with amateur equipment under less-than-perfect skies include frames with different illumination conditions and exposure times, and in these cases output scaling helps to achieve a more coherent result in statistical terms. This subject is of course open to discussion, but we shouldn't forget the fact that the integrated result of BPP is
not a valid starting image for postprocessing, but just a preview of the image, provided for convenience.
