Jump to content

  •  

CNers have asked about a donation box for Cloudy Nights over the years, so here you go. Donation is not required by any means, so please enjoy your stay.

Photo

Artifacts on brightest stars

Astrophotography Cassegrain Celestron
  • Please log in to reply
28 replies to this topic

#1 gokidd

gokidd

    Explorer 1

  • -----
  • topic starter
  • Posts: 91
  • Joined: 12 Oct 2022
  • Loc: Central Oregon

Posted 21 January 2025 - 11:16 AM

Hello, all.

I have a new troublesome blue/purplish artifact that is showing up next to the brightest stars in my stacked images of NGC 2170, the Angel Nebula.

I'm using a Celestron EdgeHD 800; ASI2600 MC-P; Celestron OAG with ASI174 Mini; and AM5.

This is the first time I've seen this problem.

 

I use Siril to do the stacking and the artifacts are appearing in the basic stacked image viewed through AutoStretch.

Drizzle seems to make it worse.

Simple stacking using the ASI Deep Sky stacking app seems to make it far less obvious or even non-existent.

What is the cause and solution?

Many thanks in advance, as I'm about to set off on a two-week trip to clear skies and would like to know I can fix this.

 

 

Artifacts
Artifacts3

 



#2 ngc7319_20

ngc7319_20

    Aurora

  • *****
  • Posts: 4,504
  • Joined: 25 Oct 2015
  • Loc: MD

Posted 21 January 2025 - 11:50 AM

Does not appear to be an optical problem.  Fainter stars do not show the artifact (though they show some optical coma from collimation error).  I'm thinking some sort of software / stacking problem.  What do the raw images look like?

 

enlarge.jpg


  • gokidd likes this

#3 gokidd

gokidd

    Explorer 1

  • -----
  • topic starter
  • Posts: 91
  • Joined: 12 Oct 2022
  • Loc: Central Oregon

Posted 21 January 2025 - 12:06 PM

I blinked through the raw exposures and do not see my troublesome artifact.

As an experiment, I tried raising the Sigma High value for pixel rejection during image stacking (from the default 3.00 to 8.00) and that seemed to help or maybe just mask the artifact.

My collimation skills are rudimentary, to say the least.

 

Screenshot 20250113 200943 ASIAIR

Edited by gokidd, 21 January 2025 - 12:24 PM.


#4 Dynan

Dynan

    Cosmos

  • *****
  • Posts: 8,527
  • Joined: 11 Mar 2018
  • Loc: NOLA

Posted 21 January 2025 - 12:49 PM

I get the same effect when I push HDR too far...'raccoon eyes'. Having a refractor, mine are usually centered. So I back off on the powder.


  • gokidd likes this

#5 SgrB2

SgrB2

    Soyuz

  • -----
  • Posts: 3,672
  • Joined: 10 Sep 2007
  • Loc: Ellicott City, MD

Posted 21 January 2025 - 01:14 PM

Here's a C9.25 image of Sirius that I took on 4/18/2022 with a ZWO 290MC

showing Sirius with purple artifacts.  At the time, I came to the conclusion

that it was due to the camera.

 

https://www.cloudyni...fect-explained/

Attached Thumbnails

  • Sirius.jpg

Edited by SgrB2, 21 January 2025 - 02:04 PM.

  • gokidd likes this

#6 soojooko

soojooko

    Apollo

  • *****
  • Posts: 1,273
  • Joined: 11 Feb 2022

Posted 21 January 2025 - 01:17 PM

I use Siril to do the stacking and the artifacts are appearing in the basic stacked image viewed through AutoStretch.

I've had similar problems that were fixed by changing the rejection algorithm in Siril. In order to troubleshoot, a couple of questions:

  • Did you try to stack data that was captured on both sides of the meridian flip?
  • Is the artifact visible on the individual subs?

Edited by soojooko, 21 January 2025 - 01:17 PM.

  • happylimpet likes this

#7 ngc7319_20

ngc7319_20

    Aurora

  • *****
  • Posts: 4,504
  • Joined: 25 Oct 2015
  • Loc: MD

Posted 21 January 2025 - 02:00 PM

I blinked through the raw exposures and do not see my troublesome artifact.

As an experiment, I tried raising the Sigma High value for pixel rejection during image stacking (from the default 3.00 to 8.00) and that seemed to help or maybe just mask the artifact.

My collimation skills are rudimentary, to say the least.

I think it is some sort of rejection or clipping problem during stacking.  The fact the raw data are OK would rule out optics as the primary problem.  The rejected area of the star image seems coincident with the coma fan from the collimation problem (as seen on the fainter stars).  Maybe the coma / collimation error is only present in some subset of the data... and hence it is choosing to reject the coma fan area on the bright stars.  Using a less restrictive rejection during stacking should fix it.  Also eliminating the optical coma would help, but that is secondary issue.


Edited by ngc7319_20, 21 January 2025 - 02:05 PM.

  • Peter Morrison and gokidd like this

#8 ngc7319_20

ngc7319_20

    Aurora

  • *****
  • Posts: 4,504
  • Joined: 25 Oct 2015
  • Loc: MD

Posted 21 January 2025 - 02:04 PM

Here's a C9.25 image of Sirius that I took on 4/18/2022 with a ZWO 290MC

showing Sirius with purple artifacts.  At the time, I came to the conclusion

that it was due to the camera.

This just looks like micro lens scattering in the sensor.  I think it is a different issue.

 

 

post-31343-0-58830100-1737482899 xx copy.jpg


  • SgrB2 likes this

#9 SgrB2

SgrB2

    Soyuz

  • -----
  • Posts: 3,672
  • Joined: 10 Sep 2007
  • Loc: Ellicott City, MD

Posted 21 January 2025 - 03:11 PM

This just looks like micro lens scattering in the sensor.  I think it is a different issue.

 

 

attachicon.gif

I think that's what I concluded in 2022 that is is micro lensing scatter.

However, the Talbot effect can give purple circles -- see the discussion

in this article:

 

https://www.cloudyni...fect-explained/



#10 gokidd

gokidd

    Explorer 1

  • -----
  • topic starter
  • Posts: 91
  • Joined: 12 Oct 2022
  • Loc: Central Oregon

Posted 21 January 2025 - 03:34 PM

 

I've had similar problems that were fixed by changing the rejection algorithm in Siril. In order to troubleshoot, a couple of questions:

  • Did you try to stack data that was captured on both sides of the meridian flip?
  • Is the artifact visible on the individual subs?

 

I did stack data from both sides of a meridian flip.

I do not see the artifact in the individual subs.

I experimented with raising the Sigma High value for pixel rejection during final lights stacking (from the default 3.00 to 8.00)


Edited by gokidd, 21 January 2025 - 05:19 PM.


#11 gokidd

gokidd

    Explorer 1

  • -----
  • topic starter
  • Posts: 91
  • Joined: 12 Oct 2022
  • Loc: Central Oregon

Posted 21 January 2025 - 03:36 PM

I think it is some sort of rejection or clipping problem during stacking.  The fact the raw data are OK would rule out optics as the primary problem.  The rejected area of the star image seems coincident with the coma fan from the collimation problem (as seen on the fainter stars).  Maybe the coma / collimation error is only present in some subset of the data... and hence it is choosing to reject the coma fan area on the bright stars.  Using a less restrictive rejection during stacking should fix it.  Also eliminating the optical coma would help, but that is secondary issue.

I tried raising the Sigma High value for pixel rejection during final lights stacking (from the default 3.00 to 8.00) Is that the correct Sigma value to change and the correct implementation?



#12 soojooko

soojooko

    Apollo

  • *****
  • Posts: 1,273
  • Joined: 11 Feb 2022

Posted 21 January 2025 - 04:35 PM

I did stack data from both side of a meridian flip.

I do not see the artifact in the individual subs.

I experimented with raising the Sigma High value for pixel rejection during final lights stacking (from the default 3.00 to 8.00)

Try stacking each set of subs separately. So one stack of the pre meridian subs, and then again for post meridian. If the problem is not in either of them, then it's the rejection algorithm. I won't bore you with any more details till you can confirm my suspicions.


  • gokidd likes this

#13 Alex McConahay

Alex McConahay

    Hubble

  • *****
  • Posts: 13,899
  • Joined: 11 Aug 2008
  • Loc: Moreno Valley, CA

Posted 21 January 2025 - 05:09 PM

I tried raising the Sigma High value for pixel rejection during final lights stacking (from the default 3.00 to 8.00) Is that the correct Sigma value to change and the correct implementation?

 

What is Sigma? It is a statistical measure of how the data is spread around. A standard deviation (the average amount data is spread around) away from average would contain some 68% of all data points.

 

At two sigmas, you get 95% of the data points. 

 

At three, you get 99.7%

 

In other words, RAISING the number of sigmas would allow MORE of the data into the stack. There would be LESS rejection. 

 

Alex


  • gokidd likes this

#14 gokidd

gokidd

    Explorer 1

  • -----
  • topic starter
  • Posts: 91
  • Joined: 12 Oct 2022
  • Loc: Central Oregon

Posted 21 January 2025 - 05:24 PM

What is Sigma? It is a statistical measure of how the data is spread around. A standard deviation (the average amount data is spread around) away from average would contain some 68% of all data points.

 

At two sigmas, you get 95% of the data points. 

 

At three, you get 99.7%

 

In other words, RAISING the number of sigmas would allow MORE of the data into the stack. There would be LESS rejection. 

 

Alex

Many,  many thanks, Alex. I appreciate learning that.

So ... it sounds like I increased the amount of signal accepted on the very high end, which I would think would help eliminate that most over-exposed area that is part of my problem? At 8 Sigma, I'm surely accepting nearly the entire signal at the high end of the range?


Edited by gokidd, 21 January 2025 - 05:24 PM.


#15 gokidd

gokidd

    Explorer 1

  • -----
  • topic starter
  • Posts: 91
  • Joined: 12 Oct 2022
  • Loc: Central Oregon

Posted 21 January 2025 - 05:26 PM

Try stacking each set of subs separately. So one stack of the pre meridian subs, and then again for post meridian. If the problem is not in either of them, then it's the rejection algorithm. I won't bore you with any more details till you can confirm my suspicions.

Hmm ... interesting, Soojooko. That gives me another experiment to try. Thank you.



#16 Alex McConahay

Alex McConahay

    Hubble

  • *****
  • Posts: 13,899
  • Joined: 11 Aug 2008
  • Loc: Moreno Valley, CA

Posted 21 January 2025 - 08:30 PM

Many,  many thanks, Alex. I appreciate learning that.

So ... it sounds like I increased the amount of signal accepted on the very high end, which I would think would help eliminate that most over-exposed area that is part of my problem? At 8 Sigma, I'm surely accepting nearly the entire signal at the high end of the range?

At eight sigma, nearly everything would be allowed in. 

 

Alex


  • SgrB2 and gokidd like this

#17 SgrB2

SgrB2

    Soyuz

  • -----
  • Posts: 3,672
  • Joined: 10 Sep 2007
  • Loc: Ellicott City, MD

Posted 22 January 2025 - 05:49 AM

An 8 sigma event has a probability of 0.00000000000012%.


  • gokidd likes this

#18 happylimpet

happylimpet

    Cosmos

  • *****
  • Posts: 7,795
  • Joined: 29 Sep 2013
  • Loc: Southampton, UK

Posted 22 January 2025 - 05:54 AM

 

I've had similar problems that were fixed by changing the rejection algorithm in Siril. In order to troubleshoot, a couple of questions:

  • Did you try to stack data that was captured on both sides of the meridian flip?
  • Is the artifact visible on the individual subs?

 

This is exactly where my brain is taking me too. Youve got some kind of minor optical issue (of debatable importance) thats makes the stars slightly asymmetric. Then combining subs from before/after flip reverses this, and the rejection algorithm tries to deal with the differences and makes a mess of it. As you note, choosing a high value for kappa will effectively reduce the rejection a great deal and stop the effect. As long as its still rejecting cosmic rays and satellites, you're all good.


  • ngc7319_20, Dynan, soojooko and 1 other like this

#19 gokidd

gokidd

    Explorer 1

  • -----
  • topic starter
  • Posts: 91
  • Joined: 12 Oct 2022
  • Loc: Central Oregon

Posted 22 January 2025 - 10:54 AM

Wow, thanks for this guidance, gentlemen.

SooJooKo, I found that stacking a small collection of exposures taken AFTER the meridian flip does not reveal the Cursed Crescent artifact.

 

Is it likely that I introduced this problem with my less-than-stellar attempt at collimation?

 

Alex --

 

At eight sigma, nearly everything would be allowed in. 

 

Alex

I also tried increasing the amount of Sigma on the low end of pixel rejection, but that doesn't seem to help, right?



#20 soojooko

soojooko

    Apollo

  • *****
  • Posts: 1,273
  • Joined: 11 Feb 2022

Posted 22 January 2025 - 11:44 AM

Wow, thanks for this guidance, gentlemen.

SooJooKo, I found that stacking a small collection of exposures taken AFTER the meridian flip does not reveal the Cursed Crescent artifact.

 

Is it likely that I introduced this problem with my less-than-stellar attempt at collimation?

Not great collimation probably does not help. But my suggestion to you would be to follow the same advice that was given to me by the Siril developer: try changing your rejection algorithm.

 

I'll explain what I did and hopefully it'll be clear and work for you:

  • Go to the Siril install directory and go into the "scripts" folder.
  • Find the default stacking script called "OSC_Preprocessing.ssf". Make a copy of that file and give it a unique name ( but keep the .ssf extension )
  • Open the new file in an editor. Look for the line with the stack command. It should look something like:
stack r_pp_light rej 3 3 -norm=addscale -output_norm -rgb_equal -out=result
  • replace with this:
stack r_pp_light rej g 0.3 0.05 -norm=addscale -output_norm -rgb_equal -out=result

This will tell Siril to use the GESDT rejection algorithm. Now try stacking the entire session again, using your new script file. It should appear in the "scripts" menu in Siril using whatever you named the file.

 

Give that a go and let us know how it went. Happy to help out if any of the above is not clear.


Edited by soojooko, 22 January 2025 - 11:46 AM.

  • gokidd likes this

#21 happylimpet

happylimpet

    Cosmos

  • *****
  • Posts: 7,795
  • Joined: 29 Sep 2013
  • Loc: Southampton, UK

Posted 22 January 2025 - 11:49 AM

Wow, thanks for this guidance, gentlemen.

SooJooKo, I found that stacking a small collection of exposures taken AFTER the meridian flip does not reveal the Cursed Crescent artifact.

 

Is it likely that I introduced this problem with my less-than-stellar attempt at collimation?

 

Yeah, this could well stem from poor collimation giving rise to the asymmetric stars. At the end of the day the data you take here isnt fatally flawed, its just that its exposing some oddness in your processing, making things a little harder. The best fix would be to get perfectly symmetric stars, but thats not likely easy to do!!!


Edited by happylimpet, 22 January 2025 - 11:49 AM.

  • gokidd likes this

#22 gokidd

gokidd

    Explorer 1

  • -----
  • topic starter
  • Posts: 91
  • Joined: 12 Oct 2022
  • Loc: Central Oregon

Posted 22 January 2025 - 02:34 PM

Not great collimation probably does not help. But my suggestion to you would be to follow the same advice that was given to me by the Siril developer: try changing your rejection algorithm.

 

I'll explain what I did and hopefully it'll be clear and work for you:

  • Go to the Siril install directory and go into the "scripts" folder.
  • Find the default stacking script called "OSC_Preprocessing.ssf". Make a copy of that file and give it a unique name ( but keep the .ssf extension )
  • Open the new file in an editor. Look for the line with the stack command. It should look something like:
stack r_pp_light rej 3 3 -norm=addscale -output_norm -rgb_equal -out=result
  • replace with this:
stack r_pp_light rej g 0.3 0.05 -norm=addscale -output_norm -rgb_equal -out=result

This will tell Siril to use the GESDT rejection algorithm. Now try stacking the entire session again, using your new script file. It should appear in the "scripts" menu in Siril using whatever you named the file.

 

Give that a go and let us know how it went. Happy to help out if any of the above is not clear.

Dang. Same artifacts showing when Drizzled. Would it be better NOT to Drizzle? And I double-checked in my log that shows "11:27:39: Pixel rejection ........... GESDT clipping
11:27:39: Rejection parameters ...... outliers=0.300 significance=0.050"

Artifacts with GESDT pixel rejection

Edited by gokidd, 22 January 2025 - 02:39 PM.


#23 soojooko

soojooko

    Apollo

  • *****
  • Posts: 1,273
  • Joined: 11 Feb 2022

Posted 22 January 2025 - 02:53 PM

Dang. Same artifacts showing when Drizzled. Would it be better NOT to Drizzle? And I double-checked in my log that shows "11:27:39: Pixel rejection ........... GESDT clipping
11:27:39: Rejection parameters ...... outliers=0.300 significance=0.050"

Double dang! I was hopeful this would help. Not sure drizzle makes a difference, but no harm in your trying to stack without it.

 

Ok, we know only stacking subs on one side of the meridian gets rid of the artifacts. So the problem is likely related to asymmetric stars ( as happylimpet suggested ) that Siril cant deal with pre and post flip due to them not lining up. I had literally the same problem that was completely fixed when using GESDT.

 

Can you post up a single sub for us to have a look at your stars?


Edited by soojooko, 22 January 2025 - 02:54 PM.

  • gokidd likes this

#24 gokidd

gokidd

    Explorer 1

  • -----
  • topic starter
  • Posts: 91
  • Joined: 12 Oct 2022
  • Loc: Central Oregon

Posted 22 January 2025 - 03:16 PM

Double dang! I was hopeful this would help. Not sure drizzle makes a difference, but no harm in your trying to stack without it.

 

Ok, we know only stacking subs on one side of the meridian gets rid of the artifacts. So the problem is likely related to asymmetric stars ( as happylimpet suggested ) that Siril cant deal with pre and post flip due to them not lining up. I had literally the same problem that was completely fixed when using GESDT.

 

Can you post up a single sub for us to have a look at your stars?

Here are two subs. One before meridian flip and the other after. Many, many thanks for hanging in there with me.

https://drive.google...?usp=drive_link

 

The only thing I find oddly interesting right now is that the ASI freebie stacking program is not producing these artifacts. I do realize ASI DeepStack is like a point-and-shoot camera compared to the lovely Siril with all its controls. 


Edited by gokidd, 22 January 2025 - 03:28 PM.

  • soojooko likes this

#25 soojooko

soojooko

    Apollo

  • *****
  • Posts: 1,273
  • Joined: 11 Feb 2022

Posted 22 January 2025 - 04:10 PM

Here are two subs. One before meridian flip and the other after. Many, many thanks for hanging in there with me.

https://drive.google...?usp=drive_link

 

The only thing I find oddly interesting right now is that the ASI freebie stacking program is not producing these artifacts. I do realize ASI DeepStack is like a point-and-shoot camera compared to the lovely Siril with all its controls. 

You need to make those files/folder public.

 

I also use ASTAP quite a lot - it produces nice stacks and doesn't have any problem with these kind of artifacts. But like yourself, I enjoy the flexibility Siril provides me, especially when using custom scripts. I'm also waiting with baited breath for Siril to introduce proper drizzling. I think it's coming in 1.4.


Edited by soojooko, 22 January 2025 - 04:10 PM.

  • gokidd likes this


CNers have asked about a donation box for Cloudy Nights over the years, so here you go. Donation is not required by any means, so please enjoy your stay.


Recent Topics





Also tagged with one or more of these keywords: Astrophotography, Cassegrain, Celestron



Cloudy Nights LLC
Cloudy Nights Sponsor: Astronomics