Startools Prerequisite No Background Calibration

[Startrek]

I’ve been using Per Channel Background Calibration in DSS for a while with no issues in Startools processing my OSC broadband or narrowband data sets
I’ve also tried the No Background Calibration setting in DSS and again no issues in Startools

Q: what is the logic behind recommending No Background Calibration in DSS as a prerequisite for Startools

Appreciate any advice on the above

Thanks
Martin

[decay]

Hi Martin,
Ivo helped me with two posts concerning background calibration:

viewtopic.php?p=12393#p12393
viewtopic.php?p=12444#p12444

At least it has impact on noise level weighting between the colour channels (last post), and the the weighting factors for the Colour module get lost.

Best regards, Dietmar.

[Startrek]

Hi Dietmar,
Thanks for your reply
I think I found my answer reviewing the DSS manual and Startools manual
As I use the Kappa Sigma Clipping algorithm in DSS all sub must have the same background value before stacking. Therefore DSS has two options to do this normalisation or background calibration
1/ Per Channel Background Calibration
2/ RGB Channels Background Calibration

I choose Per Channel Background Calibration as I’m usually only stacking 1 group due to using a OSC and this method aligns itself to the nominated reference frame.

Startools does say try to avoid normalisation or background calibration unless it’s a requirement of your nominated stacking algorithm. As I use Kappa Sigma clipping method to stack , then it is a requirement that I choose background calibration ( Per Channel Background Calibration)

Hopefully I’m on the right track here but let me know if I’m not

Cheers
Martin

[decay]

Hi Martin,

As I use Kappa Sigma clipping method to stack , then it is a requirement that I choose background calibration

That's certainly true, but I suppose, this means, you will I have to accept the downsides of this decision for the processing in ST.

On the other hand, I'm not sure, how severe the effect of these downsides will be. Ivo of course, strongly recommends not to use colour balanced data. If I understand correctly, this means, that noise reduction will work with different (wrong) strenghts for the different colour channels. And that the luminance derivation in Color module may not work correctly for different coloured parts in your image. The question is, whether this will be visible at all.

Best regards, Dietmar.

[hixx]

Hi,
IMHO this boils down to a tradeoff between able to use Kappa Sigma Stacking method vs. using linear data for ST. The question is, which method (Kappa-sigma + non-linear ST input vs different stacking method and linear ST input would yield the best results. I guess this is highly depending on multiple factors:
- number of Lightframes (with higher number the advantage of KS-stacking may decrease and SNR will increase )
- accuracy of calibration (not well calibrated datasets might rely on ST's tracking capabilities more strongly)
- overall integration time (more integration time will lower shot noise)
- noise level
- modules used in ST (please bear in mind, also other ST Modules (like SVDecon, Contrast, Sharp, HDR, Shrink,....) might produce inferior results using non-linear data)

Clear skies,
Jochen

[Mike in Rancho]

Per Channel is probably the safest, ST-wise. For sure not the other one. I remember asking Ivo a while back about this ("but DSS says you have to use it for K.S.") and he said to use K.S. anyway without it. I forget if it was here or on CN. And if I remember right there may have been a comment about DSS not putting something back the way it should be afterward? I dunno.

And really, it should still get rid of the serious outliers, even if not properly matching the S.D. you have called for. Much will depend on the range of light subs. If they vary greatly in background intensity and/or detail deviation, say from focus or seeing changes, or different conditions on different nights, or perhaps most commonly, tracking to/from brighter sky regions, then S.K. is going to work worse, or perhaps make errors. It might be good to think about that aspect when choosing a reference frame (maybe select on in the middle of the background variance, rather than best score?).

I have used per channel background normalizing in such circumstances. Or also when maybe a satellite trail doesn't go away otherwise.

I guess the issues are that this sort of thing is something we want ST doing, in order to get the luminance correct firstly and probably color star sampling and channel balancing later. Also, as far as I know DSS does not have any kind of dark anomaly filter to apply when calculating these median background values, let alone an adjustable DAF - and we all know from using Wiipe just how important DAF can be for setting these base levels.

That said, at least DSS is pretty open about what they do, and also allows you to make choices regarding usage. Others may not. ASTAP for example, as much as I like the results, has quite a few forced stacking settings. You can't even select a reference frame, for one thing. And I'm pretty sure that some sort of normalization occurs during stacking that cannot be turned off, and I have no idea what technique is being used (similar to per channel I assume?). Sometimes as it writes out the log on-screen you can see little comments that sound like background normalizing. And I am clueless about APP, Siril, and PI when it comes to these matters.

[Startrek]

I just found a previous post in ST in which Ivo helps explain the reasons why you should switch off any type of Background Calibration in DSS
I also found a post where Ivo mentions it’s ok to check “Align RGB Channels in final image” in the Stacking Parameters of DSS

viewtopic.php?t=1334

Cheers
Martin

[hixx]

Hi Mike, all
regarding APP, I think it Normalizes under tab 5) for outlier rejection, but does not change the values, but stores Normalization factors instead. From what I recall from the console output, APP will apply Normalization factors (and LNC, if selected) in tab 6 again, prior integrating the file. So it should be possible to use "normalized" outlier rejection and still leave "color calibration" unselected. This way You should get a decent compromise, provided lighting conditions are not changing too much (moon, different sessions/telescopes, mosaics) etc. In complex scenarios like these I think You need to pay Your money and take Your choice, meaning a lot of experimentation and choices. After all, this may be a lot of fun.

Clear skies,
Jochen

[Startrek]

Thanks all for your input !!

I suppose my final question to this post is -

What algorithm do most folk use in DSS with “No Background Calibration” to ensure the stacked fits data is linear when loading into Startools

NB: I am happy to continue using DSS as it’s worked well for me over the past 5 years from my DSLR days to my current cooled OSC

Look forward to your advice / comments

Clear Skies
Martin

[decay]

Hi Martin,

I used DSS before I lately changed to ASTAP (for the moment), and I still think, it's a great piece of software.
I used "Kappa-Sigma Clipping" and "No background calibration" and this was quite OK for me, as far as I can judge.

Following our discussion here, your decision will be a tradeoff, as Jochen said. And the result will depend on the specifics of your data and your personal taste as well, I think.

So I would take a pragmatic approach and take a stack that represents the data you usually capture. Stack it with and without options set. And then try to process the different versions in ST and compare, what you get.

No need for rocket science in my eyes. I guess, the differences will be quite small, especially since you are capturing high quality data sets, as far, as I can judge.

Best regards, Dietmar.