PI Question for the Experts!

14 views
Skip to first unread message

Rich Klein

unread,
Aug 30, 2025, 5:38:10 PM (8 days ago) Aug 30
to SJAA AstroImaging

Hello SJAA Pixinsight Gurus!

 

I've got one for you.  A couple of weeks ago I imaged M27, the Dumbbell nebula, in HORGB using a Minicam8 mono camera with a filter wheel over 2 nights.

 

When I integrated the data in WBPP (I believe all default options), I found that the Ha and O3 masters had these vertical 'flares' on either side of the nebula core.  See the top-left image in the attached .jpeg.  None of the RGB data had these flares, and I processed a nice RGB image despite very little integration time on RGB.  The O3 master had the same flares as the Ha, however (not shown). 

 

I originally thought the problem somehow might have occurred only on one night's data, so I re-integrated the first day only using FBPP, Fast Batch Pre-Processing.  This is the image on the top right.  No flares!

 

I then integrated both nights using FBPP and again, no flares (bottom right)!  Exact same data as the WBPP D1 + D2 image! 

 

This is weird, has anyone seen something like this before?

 

I went ahead and used the FBPP masters to process a HOO image which came out pretty well.  It required a careful GH stretch to capture the 'halo' while not blowing out the core since M27 is so bright.  


Thanks,


- Rich


Screenshot 2025-08-30 141657.jpg

Rich Klein

unread,
Aug 30, 2025, 5:42:03 PM (8 days ago) Aug 30
to SJAA AstroImaging
edit:  I just noticed that the WBPP and FBPP images are inverted wrt each other, but that does not affect the presence of the "flares". 

Francesco Meschia

unread,
Aug 30, 2025, 5:44:14 PM (8 days ago) Aug 30
to sjaa-ast...@googlegroups.com
If you look at the files put out by the WBPP pipeline, do the flare show up in the calibrated NB lights? Or in the registered NB lights?

-- 
You received this message because you are subscribed to the Google Groups "SJAA AstroImaging" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sjaa-astroimag...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/sjaa-astroimaging/65bf85cf-8eac-469d-a665-6ee887c4b272n%40googlegroups.com.

Rich Klein

unread,
Aug 30, 2025, 7:21:38 PM (8 days ago) Aug 30
to sjaa-ast...@googlegroups.com
That's a good suggestion, I will look into it.  I should say that there is no trace of the flares in the flats, darks, or biases. 

- Rich


You received this message because you are subscribed to a topic in the Google Groups "SJAA AstroImaging" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/sjaa-astroimaging/i5M-UIVwylk/unsubscribe.
To unsubscribe from this group and all its topics, send an email to sjaa-astroimag...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/sjaa-astroimaging/A44E8272-6B65-4B70-AA99-431BA86DB1F8%40gmail.com.

Jared Willson

unread,
Sep 2, 2025, 2:17:33 AM (6 days ago) Sep 2
to sjaa-ast...@googlegroups.com
Well, one of the major differences between FBPP and WBPP is that FBPP does not do local normalization. It does run through a normalization process, but it's a "global" one rather than local. 

I would recommend blinking the individual calibrated and registered H-a images to see if you can find any that exhibit the flares. I would also recommend looking at the master local normalization image in H-alpha that is generated in WBPP and see if the LN_Reference_Light file for H-alpha contains the flares. I bet this file, at least, does.

I have no idea whatsoever what the root cause is, but you might be able to get closer to a solution (other than just using FBPP which is obviously just fine) by looking at individual calibrated frames. Can you see it in any of the H-alpha frames? If you stretch aggressively? Obviously, the individual frames will be pretty noisy compared to the stack, so you may have to manually apply a pretty aggressive stretch. If the flare is there in a few of the frames (or even all of the frames), the next thing I would check is to see if I can see it in un-registered (but still calibrated) frames. The registration process is another place where FBPP works differently from WBPP, eliminating the use of thin plate splines, so it might be getting introduced there. Then, if you see the flares in the un-registered frames I'd check the raw frames. Basically, just back through the WBPP process to see where along the way the flares are being introduced.

If you see the flares in just a few of your frames (at whatever step along the way), I would just not use those individual frames. It is possible that the flares are only present in a few frames, and WBPP is giving them a very high weighting using the "PSF Signal Weight" tool. It's also possible that the frames with the issue are disproportionately being chosen in the subset used for normalization. If that's the case, and it's only a few frames, I would discard them. If it's a lot of frames, you will need to track down the root cause, and I have no idea what that might be. I'm hoping you can narrow down the source of the issue to just a few frames, but I'm worried you won't since it shows in both H-alpha and Oiii data, meaning it's not really something transitory.

Sorry, grasping at stars a bit. Just trying to come up with some ways to narrow down the processing step in WBPP that could have exacerbated the issue.

- Jared Willson

Reply all
Reply to author
Forward
0 new messages