Star artifacts left over after PI CometAlignment and integration process

Not sure if this helps as I don't use PI. If you can manually align on just the core and save, then manually align on the stars and save. Then blend the two.
This was from 2015 and having StarXterminator back then would have made it much easer.   

Comet Lovejoy,
Comet Lovejoy (mynightsky.net)

Bob Lockwood:
Not sure if this helps as I don't use PI. If you can manually align on just the core and save, then manually align on the stars and save. Then blend the two.
This was from 2015 and having StarXterminator back then would have made it much easer.   

Comet Lovejoy,
Comet Lovejoy (mynightsky.net)

When I did my 12P integration in PI  a few days ago I got something similar to yours using that technique, but as in yours, I still can see those annoying star streaks.

On 12P I haven't seen any problems with loss of coma or nucleus with StarXterminator. I did however notice that it didn't completely remove the stars, but left behind lots of dim patches that created horrendous streaks in the images. It might be an issue with the batch mode somehow but I'm not sure. I'm anxiously awaiting the new update though. 

Example of a single sub after dbe:


​​​​​​Basically all the stars are still there. So in stead I opted to remove the comet from my WBPP masters, then use the resulting star images as Operand images Thus removing stars during comet alignment. This provided better results than specific star removal software did. I only used this method on my last 12P image though.
​​

I tried dithering each image but I didn't increase the amount of pixels. StarXterminator worked a lot better for me with C2022 last year. 
​​​

As mentioned a couple times above, definitely use batch mode for going starless. There are some settings that should be adjusted but I can’t recall them off the top of my head. Here is a good video that I use for the process/settings that I’ve had very good luck with.

https://www.youtube.com/watch?v=SCMyGNZlx5o&list=LL&index=2

Hope this helps!

Dale

This is because frame-to-frame there’s enough overlap of stars in the comet-aligned images that they aren’t fully (or sufficiently) rejected by the rejection algorithm in stacking. It will stand out more so with bright stars, galaxies, etc.

After you complete comet alignment you can run StarXTerminator (batch mode) to remove the stars from all of the frames. You will want to mask the comet core to some extent (you can experiment with an individual exposure) and check your work as StarXTerminator will probably remove parts of the core and glow around it to a variable extent frame-to-frame.

Bright stars and the like will probably still show residual streaking after this process—especially if you push faint signal—but this will go a long way toward reducing artifacts which remain. In stacking the comet-only image, you can also experiment with adjusting your rejection settings. Sometimes being a bit more aggressive with rejection can be beneficial toward reducing artifacts left behind.

Rejection also works more reliably if the data is normalized.

Another thing people can do to improve this during acquisition is allow for a time delay between each exposure. This will reduce the extent of overlap between each frame. And I've also wanted to experiment with doing multiple stacks of the comet, staggered, so each stack features individual exposures with a gap in time passage thus allowing for better rejection of stars and star halos, and then stack those individual integrations. I haven’t taken a stab at that yet, though, and it may not be worthwhile depending on the data, how quickly things are moving, how much data collected, etc. But it sounds like an interesting idea to experiment with in my head.

Once you have integrated the comet-only image any remaining particularly problematic artifacts would need to be dealt with manually. PixInsight’s clumsy clone stamp is one solution to that, and maybe the preferred option if something needs to be addressed for comet subtraction in CometAlignment. But for the comet-only image in editing I prefer to deal with those remaining problem children in a much more versatile program like Photoshop. Probably no matter what you do conflicting galaxies are going to leave some fuss. They can be a bit bigger and StarXTerminator won’t reject them if they don’t look like stars.

Michael,

where in the process are these star trails being introduced? Are they an artifact left over in the comet-only images after star removal? Or are they coming from the star field images? Or are they there in the original files?

How many subexposures do you have.....LRGB or OSC?

You shouldn't need to use clonestamp for this - I think this is a processing issue.

Is this the process you are following? Comet Subtraction for the star field seems to work better than StarXTerminator IMO. If you use comet subtraction, then don't forget to add the WBPP registration reference frame into the CometAlignment file list. In my diagram below once you have created the integrated images for stars and comet, it's pretty much a regular RGB integration process after that.

Christopher Dietz:
Where does dithering fit into this workflow?

Dithering is a method for acquiring the data : you slightly shift the frame centre from a few pixels in a random direction between each subcapture. That contribute to randomize noise making it much easier to handle in processing. Therefore, dithering is not to be represented in that flowchart, as this one starts with the initial fit files.

Drizzle and Local Normalization are options when using WBPP - I switch them on when I want them. I rarely use drizzle because it is only useful when undersampling (i.e. camera resolution is less than the resolving power of your scope) which in my case is not very often.