Siril debayer and fits file format settings

[LuckyEddie]

Hi,
First post, please be kind
I'm just starting out with StarTools and I use Siril for my stacking. I believe nearly all of the Siril defaults are good for use with StarTools but there's a couple of things that I'm not sure on:

• Debayer setting. I know that it's advised that simpler is best for giving StarTools the cleanest data. Siril presents the following choices...
  • Fast Debayer is the fastest algorithm available in Siril. However, other algorithms listed below are often quite better.
  • VNG4 Threshold-Based Variable Number of Gradients, works on a 5x5 pixel neighborhood around each source pixel. It is a very good algorithm for flat areas of the image (like sky background) but produces artifacts in high contrast areas (like stars).
  • AHD Adaptive Homogeneity-Directed, is another well known debayer algorithm. However it usually shows artefacts in the background and bad star shapes.
  • AMaZE Aliasing Minimization and Zipper Elimination, is an algorithm that gives good results specially on low noise captures.
  • DCB Double Corrected Bilinear, a more recent algorithm, can show some artifacts in the background like AHD.
  • HPHD Heterogeneity-Projection Hard-Decision, is an old algorithm giving some nice results but that is quite slow.
  • IGV and LMMSE are very good when working with very noisy images. However, IGV tends to lose some chromatic information, while LMMSE is one of the most computational expensive demosaicers and needs a lot of memory.
  • RCD Ratio Corrected Demosaicing, intends to smooth the colour correction errors that are common in many other interpolation methods. It does an excellent job for round edges, for example stars, and is therefore the default algorithm used in Siril.

Which of the above would be best for StarTools?

• File format. Siril defaults to a 32-bit floating point .fit format. Is there any benefit/loss in bringing this straight into StarTools or choosing a 16-bit integer or floating point as the Siril save format? All of these options work but I was wondering about conversion losses 'under the hood'.

Regards
Ed

[admin]

Hi Ed,

Welcome to the StarTools forums!

AMaZE, RCD or VNG4 sound like they fit the bill.
"excellent job for round edges, for example stars" sounds a bit odd though, as there should be no round edges in stellar profiles...

As for file format, a 32-bit Integer file format (preferably FITS) is ideal.

Hope this helps!

[dx_ron]

As good a place as any for my first post here, as I also stack in Siril and want to get the right settings for a pristine file for ST to work on (though 'pristine' is not a word that should be associated with my attempts at astrophotography).

Here's what I have been doing:
For pre-processing:
Equalize CFA unchecked - this is the one I'm most unsure about
Cosmetic correction On

For stacking:
No normalisation


And then a different question: I'm impressed by Siril's pre-stacking gradient removal / background extraction. It fits a 1st-order function, which sounds like still linear, but I have no idea about the actual math. Is that likely to cause problems for StarTools, or be beneficial?

[admin]

And then a different question: I'm impressed by Siril's pre-stacking gradient removal / background extraction. It fits a 1st-order function, which sounds like still linear, but I have no idea about the actual math. Is that likely to cause problems for StarTools, or be beneficial?

Welcome to the forums!

I can't comment with sufficient knowledge about Siril's stacking settings. However, unless Siril has changed the background extraction functionality recently, using it is not recommended for a couple of reasons;

1. Sample setting-based algorithms destroy faint detail. You can read more about why that is, and why Wipe's implementation was specifically created to remedy this in the Wipe documentation.
2. Performing any channel normalization or background extraction will cause noise levels to vary between channels, and thus will make things like channel re-weighting for luminance purposes impossible.

You should be able to achieve superior results with Wipe in most cases, unless your gradients absolutely require a subjective approach that requires manual intervention (you have a bigger problems to worry about in that case...).

If you have problems with a particular dataset, please feel free to post it to see what the problem might be.

Hope this helps!

[dx_ron]

Thank you, Ivo.

I had not yet tried using StarTools on a dataset where I used background extraction on each individual frame, only for processing within Siril. But I have been impressed by how clean the stacked image appears in Siril.

I shall continue to rely on Wipe

I did read the Siril documentation for preprocessing more closely and it appears that the "Equalize CFA" checkbox affects only the master flat itself. I presume that is a good idea, regardless of the final destination for post-processing(?).

[admin]

Thank you, Ivo.

I had not yet tried using StarTools on a dataset where I used background extraction on each individual frame, only for processing within Siril. But I have been impressed by how clean the stacked image appears in Siril.

I shall continue to rely on Wipe

I did read the Siril documentation for preprocessing more closely and it appears that the "Equalize CFA" checkbox affects only the master flat itself. I presume that is a good idea, regardless of the final destination for post-processing(?).

To be clear (apologies if I wasn't) - you would use Wipe on the final composite you are processing as part of your workflow. E.g. you don't use it on individual frames or stacks.

If you have a particular stack where you feel Siril is being more effective (in an objective way), please do let me know.

Things that affect your master flat are fine to use. What you don't want is anything that skews or meddles with the photon-to-electron conversion counts for the RGB channels, as registered by your camera. E.g. no white balancing, no normalization (unless strictly needed). You just want Siril to stack (average out) these photon counts and stick them in the final file. Debayering of the individual light frames is allowed of course.

Hope this helps / makes sense!