Okay, it’s not just me pushing the wrong buttons… I was able to follow the comet stacking tutorial nicely (https://discuss.pixls.us/t/comet-registration-tutorial/16248). But, because I wanted the trails to be faded, I avg stacking with rejection. I get this (with 0.9.12)
.
Straight stacking with rejection has normal output (with blurred comet of course). I redid it with the comet tracking and recommended sum stacking and got the expected:
Back one step and chose avg with rejection, got the weird triple trail. Back to stacking without changing anything except to sum, and the properly trailed one returned.
Is this a bug or am I not understanding. I would have thought avg with cliping would pile the comet on top of itself like any deep-sky object, but because the stars are now in different positions, they would get averaged “down” or clipped out.
Did you aligned on stars first?
Yes straight stacking on stars with rejection has normal output with blurred comet (at lower right) .
.
I was as careful as I could be making sure I used the r_pp sequence. As you can see in the first post above, the comet tracking worked well. The only thing changed was sum vs median-with-rejection. And I can actually go back and forth with stacking: stack on sum, see the log is finished, the image has properly trailed stars, go back to the stacking tab, change the name of the final stack, rerun with median and rejection, and get the weird triple trail. It’s as if the median-rejection button when in tracking mode is reading the original offset instead of the newly computed ones. The log states “Stacking will use registration data of layer 1 if some exist.” is it possible that that array did not get updated?
First, be aware that there is no median with rejection algorithm, only mean with rejection. Our median algorithm does not take into account registration data and should not have any rejection algorithm available.
I use to align on comet with no issue very often (and with mean/rejection, and not only me), so I’m not sure to understand why it is wrong on your computer. One thing, the “cumul reg data” is a kind of trap. If you are doing several tests it will add the shifts and your result will be wrong.
Thanks for the explanation, things make more sense now! Forgive my mixing of the terms, it’s so easy when similarly named options are nearby:
I guess comet stacking with rejection can be a low priority request for a feature then. A couple of years ago, unaware of Siril, I coded up a Perl script to use ImageMagick to shift the images by the expected comet motion (when it was invisible in a single frame), then pumped the images back through a stacker (I was unaware of Siril at the time) using either median or average sigma clipping. The stars are then less bright. I ran it here out of curiosity. I can’t quite get the same contrast because of the loss in converting images to BMP and back:
And the one from Siril Sum:
I suppose if one is then removing all the trails with a mask, it really doesn’t matter how bright or faint they are.
So just to be clear for those following, use SUM stacking for comets:
Consider this thread closed!
I think you misunderstood. We already can align a comet, and then stack images using mean with pixel rejection. I often do it. For all my comet images.
Hmmmm. It appears to work for you but not for me. On a clean start loading sequence, choosing comet/asteroid, clicking on point 1 and 2, and cumul is not checked, running that and then in stacking I do this
I still get the funky
With Sum, I get a properly trailed star with fixed comet.
My version 0.9.12 on Win 10 does this. I am not doubting that you are able to do it. Either a bug was introduced since your version, or it’s a Win 10 thing, or there is something super subtle in the instructions that is not explicit enough.
Sorry to badger about this… when you are on the stacking tab and do not choose sum, what do you do? My choice above is not working.
In fact, what you see is normal.
Take a look to my image.
Stars look fainter because of the rejection. And the shape could be confusing too, because of the rejection again.
I did use 0.9.12 with same parameters. For me it is ok.
Ah, I see your bright stars have a funky shape too (black spot with double star trail).
So it’s safe to say that the algorithm is behaving similarly on our two platforms and two different data sets. If it comes down to taste, I will take sum stacking and mask out the brighter stars.
Thank you again for following through with this - your patience and willingness to help is magnificent.