I am working on a substantial project. As part of this, I would like to generate interim, proof stacks for which I am willing to sacrifice quality for speed. I am writing a script to run to keep everything consistent. I am beginning with well calibrated .fits frames, so I am curious to learn what parameters I can use for the register and stack commands to squeeze speed out of Siril.
On the registration command am doing 1 pass and have dialed down the number of star pairs required using -maxstars=500. Can I gain noticeable speed by forcing a transformation method?
On the stack command I have added the -fastnorm switch. I am using ‘rej 3 3’ and ‘-norm=addscale’. Is there noticeable speed to be gained by eliminating normalization, or by using a different stacking type (sum|mean|etc)?
Are there other tricks that others can recommend?
Oh, when I am ready to make a good stack for processing I will be pulling out all the stops for max quality and will not worry about speed at that point.
It depends how much you are willing to sacrifice quality I would say…
For registration, 1 pass will definitely be faster. You can probably lower number of stars to 100 if your frames are relatively steady (no large drift during the session, meridian flip does not matter though). Transformation type won’t have any influence. Interpolation does, so you should probably use bilinear or nearest neighbor, at the cost of less sharp stars.
Now regarding stacking, that’s where you will need to make more drastic quality-related choices.
If speed is much more important than quality, you could skip altogether the normalization phase (fast_norm is faster but it still requires to open the images and compute some simpler stats). But you may end up with really bad stacks if your conditions have evolved (change in background level mostly).
You can also skip the rejection step. But again, you may see bad pixels and satelite trails in your stacks.
Then depending on your resources (nb cores, ram) an option may be to try sum stacking. It may, in some cases, be faster…but you would have to test for your setup.
Hope this helps,
Cheers
Cecile
PS: one of the reason why sum is usually faster is that it skips normalization and rejection. So make sure you compare apples with apples (i.e mean with nonorm and no rejection). Then it will depend on your computer as the way to handle the images is quite different between sum and mean (one reads whole images while the other read bands across the whole sequence). In any case, worth mentionning, though you probably know that, that if speed is at stake, working from a SSD is a must. Mechanical HDD will be clogged by the read/write operations.