3.71
#...
·
·
3
likes
|
|---|
|
Looking for some insight into what might be the reason for the issue I'm having and/or suggestions to prevent it or fix it. While trying to process my subs of 12P/Pons-Brooks using PixInsight's CometAlignment process (as described in "Insight PixInsight" by Warren Keller) I noticed some 'mini comets' trailing alongside the brighter stars in the integrated image. I execute the CometAlignment process as described and then integrate the comet aligned subs with Sigma Low set to 10 and Sigma High set to 0 (Sigma Clipping as the Rejection Algorithm). I then run an integration of the original registered images followed by StarXTerminator to get the stars. Using PixelMath I combine the two. The result is rather good, but these training artifacts on the stars are the problem (see image). Any suggestions or corrective action that I can take to eliminate them? I could simply spend the time using CloneStamp but I thought somebody may have already experienced this and have a more satisfying solution.  |
6.08
#...
·
·
5
likes
|
|---|
|
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)  |
1.91
#...
·
·
4
likes
|
|---|
|
Hi, you can use StarXTerminator in batch mode on the calibrated, comet aligned subs before integrating them. You may have to use a mask on the comet to prevent it from getting removed by StarX. Johannes |
0.00
#...
·
·
2
likes
|
|---|
Bob Lockwood: 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. |
7.46
#...
·
·
1
like
|
|---|
| Using SN++ V.2 recursively on the comet-aligned frames should result in no risk in removing the comet's nucleus. I suspect you didn't dither aggressively otherwise you would see a clean removal of the stars once the comet-aligned frames are integrated. |
4.36
#...
·
·
2
likes
|
|---|
|
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. |
|
0.90
#...
·
·
3
likes
|
|---|
|
You need to CometAlign subs that have been Calibrated and Cosmetically Corrected in WBPP. Then remove the stars from the Comet Aligned subs using StarX in batch mode. Create a mask to protect the nucleus from Xtermination. Use LocalNormalization and ImageIntagration to create starless R, G, and B masters. Use the starless masters in CometAlignment to subtract the comet from sets of R, G. and B subs that have been registered in WBPP. Integrated the subs without the comet to create starfield RGB masters. Use StarX to extract the stars from each master and use CloneStamp to clean up artifacts in the starless image. Then add the stars back in. You probably won’t get star trails with this approach, but there will be comet subtraction artifacts that require removal. Create an RGB master of the starfield and color calibrate using SPCC. Don’t discard the SPCC report. Create an RGB master of the Comet only data and process using BackgroundNeutralization and then ColorCalibration using the White Balance weights provided in the SPCC report. Combine the comet and starfield images using the ImageBlend script in the Screen mode. Adam Block has a good set of tutorials on this process that will cover some if the finer details that I glossed over. |
15.85
#...
·
·
1
like
|
|---|
|
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 |
0.00
#...
·
·
1
like
|
|---|
Johannes Möslein: *** yes, this is a good idea! *** |
2.11
#...
·
·
4
likes
|
|---|
|
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. |
0.00
#...
·
·
2
likes
|
|---|
|
As stated above, it's your processing causing this. You should subscribe to Adam Blocks' Comet Acadmey. Detailed, easy to follow, and incredible results. Worth every penny. He does the processing in PixInisght. RC Astro plugins make life much easier too. StarX, BlurX, and NoiseX. From the evening of March 10.  Comet 12P (Askar 120) |
0.90
#...
·
·
2
likes
|
|---|
|
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.  |
0.00
#...
·
|
|---|
| Where does dithering fit into this workflow? |
3.61
#...
·
|
|---|
Christopher Dietz: 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. |
|
0.00
#...
·
|
|---|
Christopher Dietz: I’m sorry, I meant drizzling. I’ve had trouble using drizzle integration on comet projects. Have you been able to drizzle both the comet and starfield layers of your images before combining them? |
|
0.90
#...
·
|
|---|
| 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. |
|
3.71
#...
·
|
|---|
|
As James points out, the frame-to-frame overlap of the stars is the culprit here. Image integration, even with the rejection algorithm settings set at maximum aggressiveness (Sigma Low set to 10 and Sigma High set to 0) didn't eliminate the stars sufficiently. fjwidmann, James and others suggested doing a batch StarX (which I tried) but the bright leading edge of the coma got removed in some of the subs. James recommended using a mask to help protect the comet's coma - I know how to create masks and such but not sure how to do this in conjunction with StarX. In the interim I did apply CloneStamp and ended up with a respectable image: 12P/Pons-Brooks (Michael J. Mangieri) - AstroBin. |
