Jump to content

SkySurveyBanner.jpg.21855908fce40597655603b6c9af720d.jpg

Help please with strange artefacts in my imaging of M42


oymd

Recommended Posts

Two nights ago, after fixing my mount, and achieving steady guiding, I attempted M42.

Scope is 350FL, 70mm refractor, ASI294MC Pro, Guiding, and used the Optolong UV/IR filter.

I took 10s, 30s and 60 second subs.

I also took corresponding darks at same temperature (-5C) and Flats and dark flats at the end of the night.

The flats are clean, and I checked them, no artefacts.

The resulting masters have terrible artefacts, and I cannot find the culprit?

I stacked the subs in WBPP, and ALL the three masters had the same artefacts.

I also tried stacking just the 30s subs alone WITHOUT ANY CALIBRATION files, and the artefacts are there.

Would appreciate if someone can advise as to why this artefacts are showing up?

Attached are the Masters as well as subs from each stack, in case anyone has the time to have a look.

Many thanks

 

 

 

Untitled 2.jpg

Untitled.jpg

masterDark_BIN-1_EXPOSURE-4.82s.xisf masterDark_BIN-1_EXPOSURE-10.00s.xisf masterDark_BIN-1_EXPOSURE-30.00s.xisf masterFlat_BIN-1_FILTER-NoFilter_CFA.xisf 2022-02-15_21-07-45__-4.90_30.00s_0006.fits 2022-02-15_23-18-35__-4.90_10.00s_0016.fits 2022-02-15_23-11-16__-4.90_60.00s_0002.fits

Link to comment
Share on other sites

I downloaded the three subs and stacked them in deep sky stacker and even stretching the result I personally couldn't see the artefacts.  Not sure what would happen if the darks and flats were added.  Here's the resulting FTS file, and a screen shot.  Can't answer your question as to what is causing the issue, but my guess is that is "generated" as part of the stacking process as, as far as I can tell,  it doesn't seem to be part of the data captured.

 

ds2.thumb.png.b237516337bdcffcb5f7702663682d2d.png

 

test.FTS

 

Edited by malc-c
  • Like 1
Link to comment
Share on other sites

14 minutes ago, geordie85 said:

I'm assuming that you didn't dither?

 

13 minutes ago, malc-c said:

I downloaded the three subs and stacked them in deep sky stacker and even stretching the result I personally couldn't see the artefacts.  Not sure what would happen if the darks and flats were added.  Here's the resulting FTS file, and a screen shot.  Can't answer your question as to what is causing the issue, but my guess is that is "generated" as part of the stacking process as, as far as I can tell,  it doesn't seem to be part of the data captured.

 

ds2.thumb.png.b237516337bdcffcb5f7702663682d2d.png

 

test.FTS 133.84 MB · 0 downloads

 

Thank you for your replies.

Yes, the artefacts do not show up in the individual subs.

I have been advised to generally Dither every 5 minute sub. When I use the L-eXtreme, I usually take 300s subs of Nebulae. I dither EVERY SUB.

I used the same calculation when I was imaging M42.

For the 2 minute subs, I dithered every THREE subs. for the 30 second subs I dithered every 10 frames etc, so basically dithering every 5 minutes or so. With the 10s subs, I dithered every 25 subs.

 

Could be the effect of UNDER DITHERING? If so, how often should one dither with 10s subs?

Edited by oymd
Link to comment
Share on other sites

I cant see the problem in the raw subs. Also cant open the .xisf files so cant check the masters, but from the looks of your screenshot it does look like walking noise. It could also be the result of some funny sigma clipping issue where a bad sub is chosen as the reference by the stacker and so a lot of good data that deviates from the bad sub gets rejected in the end. I had this happen with deep sky stacker once, but not sure if its all that common of a problem.

Your dithering schedule looks good, i dont think i would bother dithering more often. I dither every 10 subs when i shoot 30s ones, so every 5 minutes as well. I also dither in RA only and it still works well like this so not sure whats the problem. Can you check your PHD2 logs and see if the dithering actually took place? And if it did, how many pixels was the dithering set to. If your dithers are very small, like maybe 1 or 2 pixels i think they might not work that well with OSC cameras.

  • Like 1
Link to comment
Share on other sites

44 minutes ago, ONIKKINEN said:

I cant see the problem in the raw subs. Also cant open the .xisf files so cant check the masters, but from the looks of your screenshot it does look like walking noise. It could also be the result of some funny sigma clipping issue where a bad sub is chosen as the reference by the stacker and so a lot of good data that deviates from the bad sub gets rejected in the end. I had this happen with deep sky stacker once, but not sure if its all that common of a problem.

Your dithering schedule looks good, i dont think i would bother dithering more often. I dither every 10 subs when i shoot 30s ones, so every 5 minutes as well. I also dither in RA only and it still works well like this so not sure whats the problem. Can you check your PHD2 logs and see if the dithering actually took place? And if it did, how many pixels was the dithering set to. If your dithers are very small, like maybe 1 or 2 pixels i think they might not work that well with OSC cameras.

Dithering is set to 5 pixels. 

Link to comment
Share on other sites

52 minutes ago, ONIKKINEN said:

I cant see the problem in the raw subs. Also cant open the .xisf files so cant check the masters, but from the looks of your screenshot it does look like walking noise. It could also be the result of some funny sigma clipping issue where a bad sub is chosen as the reference by the stacker and so a lot of good data that deviates from the bad sub gets rejected in the end. I had this happen with deep sky stacker once, but not sure if its all that common of a problem.

Your dithering schedule looks good, i dont think i would bother dithering more often. I dither every 10 subs when i shoot 30s ones, so every 5 minutes as well. I also dither in RA only and it still works well like this so not sure whats the problem. Can you check your PHD2 logs and see if the dithering actually took place? And if it did, how many pixels was the dithering set to. If your dithers are very small, like maybe 1 or 2 pixels i think they might not work that well with OSC cameras.

I’m also attaching the PHD2 guide log. 

 

Edited by oymd
Link to comment
Share on other sites

2 hours ago, ONIKKINEN said:

.html file format? Something went wrong, its supposed to be a .txt file

Yes. Sorry. I tried to upload it from my phone. 
will upload it from the PC once I get home. 

Link to comment
Share on other sites

To me it looks like the dithers do happen on schedule and like they should. The log says your settling has failed, but i dont think that has to do with dithering success but is just the result of your settings.

dither.PNG.d69853753e11fb786314c617002b651b.PNG

You have here the dither spike as it should in the directions ordered. The "settling failed" notification is there i think because you have a high settling time of 120 and strict settling limits. Not sure why your settling limits in the log appear to be less than 1'' but they are set as 1.5 pixels in NINA which would obviously be a lot more than that 🧐. I dont think this has anything to do with your issue, but this does waste 55 seconds after a dither. Im pretty sure NINA starts the next exposure only after PHD2 informs NINA that settling has completed, and since it fails for you every time it has to wait the 55s you have set it to in the settle timeout setting.

  • Like 1
Link to comment
Share on other sites

13 minutes ago, ONIKKINEN said:

To me it looks like the dithers do happen on schedule and like they should. The log says your settling has failed, but i dont think that has to do with dithering success but is just the result of your settings.

dither.PNG.d69853753e11fb786314c617002b651b.PNG

You have here the dither spike as it should in the directions ordered. The "settling failed" notification is there i think because you have a high settling time of 120 and strict settling limits. Not sure why your settling limits in the log appear to be less than 1'' but they are set as 1.5 pixels in NINA which would obviously be a lot more than that 🧐. I dont think this has anything to do with your issue, but this does waste 55 seconds after a dither. Im pretty sure NINA starts the next exposure only after PHD2 informs NINA that settling has completed, and since it fails for you every time it has to wait the 55s you have set it to in the settle timeout setting.

Many thanks

Can you please advise me how to populate my Dither settings to fix this issue?

Link to comment
Share on other sites

9 minutes ago, oymd said:

Many thanks

Can you please advise me how to populate my Dither settings to fix this issue?

I think you can drop the settle timeout and min settle time to much lower, like maybe 10 and 10 seconds. Your guiding looks pretty good and stable so i dont think you benefit from having the times be so long.

I am not sure however how to change the settling limits setting. I would assume that its the 1.5 pixels you have set in NINA but the guide logs say otherwise. Never had this issue myself so not quite sure how to fix it, but this doesn't really make the dithering fail and just prolongs the settle time unnecessarily so not the main issue here.

If dithering failed for some reason and its not apparent in the logs you can see it if you blink the frames in Pixinsight before registering them. Just blink a bunch of the frames and you should see a very obvious sudden jerk when dithering happens and if it does not happen well then dithering did not happen for some reason.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue. By using this site, you agree to our Terms of Use.