Random artifacts around stars

[Richard_]

I've recently taken subs of M45 in mono-LRGB and noticed some weird artifacts around the stars. I have two questions:

1. What is causing the weird artifacts?
2. How can I get rid of them during post?

My setup is as follows:

• QHY268M camera
• QHYCFW3 filter wheel
• Antlia LRGB filters (36mm unmounted)
• Redcat51
• Buckeyestargazer 3D printed masks for filters

I stacked each LRGB channel using PixInsight WBPP with Winsorised Sigma Clipping, default values. After performing background extraction and linear fitting each sub, I merged the master lights via LRGB combination. I saw what looked to be hot pixels and red artifacts on the lower left of stars so decided to make an RGB image using channel combination. The hot pixels have disappeared (so are likely from L channel) but the bright red artifacts are still there. See Fig.1 which shows LRGB (left) and RGB (right) combination.

Fig.1 - LRGB and RGB combination

 

I reviewed the master light for each colour channel and these artifacts appear most prominantly in the Red channel (as you'd expect) but I can also see it in the Blue channel. I decided to blink the registered subs for each channel to see if this artifact appears all the time, or just in individual subs. I created a separate GIF of each blinks which are shown below.

• You can clearly see some occassional "blips" in the L and B channel subs
• These blips are seen in allk the Red subs
• Nothing is observed in the Green subs

Finally, I decided to do a blink of the raw Red channel data to prove these aren't hot pixels being missed from pixel rejection or created during calibration. My image acquisition takes a sub with a given filter, then changes to the next one (e.g. L-R-G-B) and after one complet LRGB cycle, I perform a dither. This final GIF image of the raw data clearly shows regular hot pixels as static along with the aforementioned artifact continues to follow the stars. This proves the red artifacts aren't being introduced as part of the calibration process. Not sure why pixel rejection didn't identify and reject these artifacts, are there any parameters which could help remove this?

 

M45 L subs (registered)

 

M45 R subs (registered)

 

M45 G subs (registered)

 

M45 B subs (registered)

 

M45 R subs pre-calibration (raw)

Edited February 20, 2023 by Richard_
Clarify wording

[Lee_P]

This is a real head-scratcher, I'm not sure what could be going on. Hopefully some SGL clever-clogs can shed light on the situation, but if not then the only thing I can think of is to go through the arduous process of changing one thing at a time to try and work out if it's something in your image train causing this. Could the 3D printed masks be a suspect?

[Richard_]

12 hours ago, Lee_P said:

This is a real head-scratcher, I'm not sure what could be going on. Hopefully some SGL clever-clogs can shed light on the situation, but if not then the only thing I can think of is to go through the arduous process of changing one thing at a time to try and work out if it's something in your image train causing this. Could the 3D printed masks be a suspect?

I had originally thought about the 3D printed masks since I recall the centre face being a little shiny during installation. However, a week prior to imaging M45, I imaged the comet C/2022 E3 (ZTF) using the exact same setup and no red artifacts were observed nor were there what appears to be hot pixels in the Luminance channel. If it were the filter masks, then I should have seen this in my comet subs right?

I believe something has changed between shooting the comet (07-Feb-2023) and shooting M45 (13-Feb-2023). When not in use, my setup is covered with the Telegizmos 365 cover like it has done so over the past 12 months, so I hadn't even moved my telescope between these dates never let alone make any hardware adjustments/changes. Could an external light source (street lamp, bedroom light etc.) reflecting/shining into the objective lens cause these types of artifacts or would this light intrusion appear as a regular light pollution gradient across the image?

In case it proves useful, here's a brief timeline of recent events which involves my camera:

• 05-Feb-2023   -> remove camera from filter wheel, performed tilt test on rig
  • Note: no tilt detected so no adjustment made, see link to thread below
• 06-Feb-2023   -> remove original 3D filter masks, replace with replacement 3D printed filter masks. Placed camera, filter wheel etc. back onto Redcat51
• 07-Feb-2023   -> captured LRGB subs of Comet C/2022 E3 (ZTF) 
  • Note1: red artifacts not present in these subs/final image (see link to second thread below)
  • Note2: the image of my Redcat51 in the linked thread is a couple of months old and shows an adapter to the filterwheel with black tape covering the holes. In late December 2023 this was swapped to a solid adapter where no tape was required, so no light leaks)
• 13-Feb-2023   -> captured LRGB subs of M45 (per this topic) and noticed red artifacts in R subs and hot pixels in L channel
  • Note: no physical or software changes performed between now and setup from 07-Feb-2023

 

 

Edited February 20, 2023 by Richard_
Deleted repeated bullet point

[sharkmelley]

The star blips are almost certainly caused by some subs that have "doubled stars" because of wind gusts or periodic error.  Blink through your raw subs and you are likely to find the offending ones.  Remove those faulty subs from your workflow.

Blinking your subs should be a standard part of your processing because it catches a whole range of issues.

Mark

Edited February 21, 2023 by sharkmelley

[assouptro]

6 minutes ago, sharkmelley said:

The star blips are almost certainly caused by some subs that have "doubled stars" because of wind gusts or periodic error.  Blink through your raw subs and you are likely to find the offending ones.  Remove those faulty subs from your workflow.

Mark

My thoughts too

I have a heavy rig on a medium mount and when it’s gusty I get moments when there are double stars 

I always blink my subs and often remove 20-30% depending on the wind, if it’s particularly gusty I may only keep 20-30% 

I hope you get to the bottom of it 

Bryan 

[Richard_]

Thanks for your suggestions Mark and Bryan. The GIF images above show all subs for each channel rather than a selection, and seeing as these artifacts affected almost all the Red subs and a handful of Luminance and Blue, I had originally ruled out wind gusts etc because what are the odds that 95% of the time they occurred during Red exposure? Normally I blink my subs and reject obvious issues, if I do that here then all my Red subs go in the bin! 

My mount runs with Periodic Error Correction enabled which is no change as of recent. 

My filter sequence isn't technically LRGB, but from farthest focus step to closest to reduce the effect of backlash (eg could be something like RBGL). I wonder if the Red filter is first in sequence, and perhaps I don't give enough time to settle after a dither, so the camera starts exposing before guiding is restored and settled? This may explain the moving artifacts in mostly Red channel. 

[sharkmelley]

3 hours ago, Richard_ said:

I wonder if the Red filter is first in sequence, and perhaps I don't give enough time to settle after a dither, so the camera starts exposing before guiding is restored and settled? This may explain the moving artifacts in mostly Red channel. 

That certainly sounds like a plausible explanation.

[Richard_]

OK, I think I'm getting somewhere!

Below is a screenshot of the directory with my LRGB subs sorted by capture date. My imaging sequence was R-G-L-L-B (largest focus offset down to smallest) which was repeated throughout the night as shown by the yellow squares in the screenshot. After a single RGLLB sequence is performed, my telescope would then perform a dither in a random direction which means the first sub after dithering is with the Red filter!

• If the time allowed for slewing/guiding to settle is too short, then the camera may start exposing whilst the mount is trying to bring the object back into the frame.
• This would explain why all the red subs have a duplicate star in a non-fixed direction (e.g. the position changes slightly each time)
• With regards to the Blue and Luminance subs, these ones may have just been caused by wind hence the very low frequency of their occurrence.

Going back to the screenshot below, after subtracting the 300s exposure length the typical delay between images is ~10s which includes electronic focus adjustment via known offsets. After a dither, the delay increases to ~30s. Based on this, I think I'll take a look at the settle time after dithering and my settings in PHD2 for resuming guiding to see if this is generous or not.

Thanks for the suggestions guys.

[sharkmelley]

That all makes complete sense!

[assouptro]

It looks like you have a strong candidate for the problem! 

No-one said this hobby is easy but it is satisfying when you solve yet another issue this hobby throws at you! 

I hope that’s it! 
 

Bryan 

[Richard_]

I'm hoping to have closure on this issue! Since my Red subs for the above M45 sequence cannot be used, I decided to shoot M45 again tonight. My equipment/setup has not changed since the above imaging session so everything is the same.

From my previous post, the likely culprit for causing the wobbling during exposure of Red subs could be inadequate settle time for guiding after performing a dither before shooting the Red subs . Before I started imaging tonight, I tweaked some settings in NINA to hopefully give more settling time. The changes were as follows:

• Disable guiding during filter change
• Increase guiding settle time from 10s to 15s

I began my imaging sequence on M45 including the same filter sequence of R-B-L-G. I have now performed three full cycles which includes a dither after each Green sub. I'm pleased to say that I do not see these artifacts on any of the Red subs shot tonight! M45 is due to drop off my horizon at 22:30 tonight, so I'll have to review all the subs tomorrow to confirm this has been fixed.

Thanks again for the support and advice on this.