Star Alignment - Question about the resulting image size, and 'pixel padding'

[Niall Saunders]

Juan,

In StarAlignment there only appears to be one possible method of controlling the final size and shape of the output images, and that is that the output images will presumably be the same size and shape as the reference image - with a zero ADU value being used to 'pad' the (empty) space of any images that have had to be translated/scaled/rotated.

If that assumption is correct, then how does the Normalisation process handle these 'zero ADU' padding values when ImageIntegration tries to stack the aligned images?

Is there any benefit in providing StarAlignment with a facility to perform an automatic post-alignment 'crop' such that none of the images will have any 'padded' zero-ADU values?

What about the ImageIntegration clipping algorithms that rely on 'percentile clipping', how do they handle the 'outliers' that must be present wherever a zero-padded ADU value is encountered?

Is that, in fact, the function of the Region Of Interest (ROI) parameters in the ImageIntegration dialogue box?

If so, should the user be capable of defining the ROI using the same interface as is available for DynamicCrop, having first presented the user with a very quick 'AverageCombine' of all images in the data set?

Once again, thanks in advance,

[Juan Conejero]

Hi Niall,

the output images will presumably be the same size and shape as the reference image - with a zero ADU value being used to 'pad' the (empty) space of any images that have had to be translated/scaled/rotated.

Correct.

how does the Normalisation process handle these 'zero ADU' padding values when ImageIntegration tries to stack the aligned images?

ImageIntegration ignores all pixels outside the [0.00002, 0.99998] normalized range for all statistics calculations. It treats those pixels as if they wouldn't exist when it comes to compute values such as the mean, median, standard deviation, and so on.

What about the ImageIntegration clipping algorithms that rely on 'percentile clipping', how do they handle the 'outliers' that must be present wherever a zero-padded ADU value is encountered?

As for rejection, black pixels are treated just as any other pixel values.

It has been suggested in other thread, that an additional pixel rejection could be implemented for pixels below a specific value. I think this is a good idea and I in fact will try to implement it as soon as possible.

Is that, in fact, the function of the Region Of Interest (ROI) parameters in the ImageIntegration dialogue box?

No. The ROI is used to restrict ImageIntegration's rejection and integration tasks to a specific rectangular region. This is useful to accelerate testing ImageIntegration parameters, as the computational complexity of those tasks is linearly proportional to the number of processed pixels.

Note that when a ROI is defined ImageIntegration still computes image statistics for the whole images (or retrieves them from its private cache of file data). In this way a ROI works for integrated files must like a preview works for an image in PixInsight.

If so, should the user be capable of defining the ROI using the same interface as is available for DynamicCrop, having first presented the user with a very quick 'AverageCombine' of all images in the data set?

Even easier than that: my intention is to allow the user to select a preview defined on any image to acquire its geometry as the ROI rectangle. In this way you just have to open one of the images to integrate, apply an automatic STF, define a preview on a suitable region of interest, and select it on ImageIntegration.

Once again, thanks in advance,

Thank you for giving raise to such interesting topics for discussion.

[Niall Saunders]

Thanks again Juan,

ImageIntegration ignores all pixels outside the [0.00002, 0.99998] normalized range for all statistics calculations. It treats those pixels as if they wouldn't exist when it comes to compute values such as the mean, median, standard deviation, and so on.

I 'think' I understand that - in other words, AFTER normalisation, any pixels outside the bracketed range shown in your reply, CANNOT take part in the statistical analyisis. So, presumably, after normalisation, the 'padded values' still remain within the exclusion zone, and are therefore simply 'ignored' thereafter?

pixel rejection could be implemented for pixels below a specific value

Isn't this just a variation of your "Min/Max" clipping system?

One point that I haven't mentioned is the fact that your Image Integration dialogue box is becoming rather unwieldy - it is becoming too 'tall' to fit on a 1900x1200 screen workspace. I don't know how best to resolve this. I do have some ideas, and would be happy to discuss these in a more appropriate thread.

ROI

I think I understand this now - you still do a "whole-of-image" statistical analysis - most likely ONCE (at the start) for a given  a data-set. Then ONLY the area within the ROI is passed to the actual "stacking" routine, and the ouput image is then only the size of the ROI. When parameters are adjusted thereafter, the file-cache information is easily, and quickly retrieved, the new integration parameters are applied, and the ROI image is recalculated. Very clever. And even more clever when the ROI is an image preview 

I'm looking forward to the new module already !! (I am sure that you realise by now that I would NEVER now entrust my precious pixels to ANY other Integration process out there - there is no doubt in my mind that PI gives greater flexibility, and better results, than anything I have encountered - and, remember, I am testing these routines with Meade DSI data - dirty, nasty stuff, often containing more outliers than real values  )

Cheers,