I use PI for post processing the Siril output, and find that the NSG script does a great job.
Ideally, I would like to take registered files from Siril, run NSG then integrate.
However, NSG looks for NOISExx data in the FITS keywords to help with the weighting. This is apparently best done before registration - NormalizeScaleGradient Script - Page 6 - Astronomy Software - The Backyard Astronomy Space
I could not find these in the Siril output FITS headers, but I suppose it is possible as the Registration has a noise -weighted option.
Would it be possible to add these headers in Siril as part of the calibration process?
This value is a Pixinsight value, for Pixinsight processes. This is not a standard.
Our computation of noise is different and I’m not sure we should try to do it.
What I mean. If we do it, I’m not sure you’ll get the results you want.
Thanks for the clarification.
I think it will be useful. From what I can make out, the noise is used for weighting and helping the manual selection of reference and best frames in NSG, after which it anyway uses its own LN algorithm.
I have tried NSG on Siril stacks - it works, but NSG has to compute the Noisexx headers from the registered data, which is not so accurate. If Siril measured and inserted that information before registration, it would effectively be the same utility as in PI.
I do not think (may be wrong) that the methodology of measuring noise (between PI and Siril) would make a difference, its more the difference between measuring in registered and unregistered frames. It is important from point of view of relative weighting - the absolute number is not used as far as i know in the NSG algorithm.
So if there is no problem as such, would be a nice feature to have. Maybe sometime someone would make a NSG like addition to Siril also using this.
Hello, it may not be technically difficult, but in terms of data management, we should ask ourselves if we want to store this data and others in the FITS headers or in the sequence files like we do now. Duplicating data risks introducing incoherences and requires overrides to recompute in case of data change. It’s in fact not so simple.
Yes I understand. This was simply a request with the intention of increasing compatibility between Siril and NSG (a very popular PI gradient normalization script).
If it is not suitable for Siril, that is fine.
Thanks for considering it.