Help needed - fireworks galaxy processing

[Moonstruck]

Hi,
I am having some real difficulty processing the fireworks galaxy (NGC6946) and am hoping someone can help. I took about 4 hrs of 2-min subs last night under what appeared to be ideal conditions, but when I went to process it in startools there were 2 issues: 1) when the raw stack included lights, darks, and flats, stars were present but the image was not visible at all after using autodev. When I removed the darks from the raw stack the image appeared after using autodev, which tells me there was something wrong with my darks, so I removed the darks from the raw stack. 2) I then tried to process it using only lights and flats, and the image appeared, but there was excessive noise after using the wipe function. The noise was so severe I couldn't process it any further. Can anyone assist in identifying the cause of the noise, or let me know how to remove/suppress it? It looked a little bit like walking/raining noise so I tried the noise reduction module and set the walking noise angle to what I thought was appropriate, but still had no success. Note- I have no idea what to set the other noise reduction settings to (#pixels, etc).

The autosave (raw stack) link is below if you can try processing it to diagnose the noise problem or other issues. I also included the sharpcap capture file below if that helps. Any help will be appreciated! Thanks!

Equipment: Celestron C8 with 0.7 reducer, ZWO asi 294 camera, EQ6 mount. Sharpcap pro software used for imaging.

Link to dss autosave file (with light and flat frames only):
https://drive.google.com/file/d/1S5R8DC ... sp=sharing


Sharpcap capture file:
[ZWO ASI294MC Pro]
FrameType=Light
Debayer Preview=On
Pan=528
Tilt=0
Output Format=FITS files (*.fits)
Binning=1
Capture Area=3104x2822
Colour Space=RAW16
High Speed Mode=Off
Turbo USB=40
Flip=None
Frame Rate Limit=Maximum
Gain=121
Exposure=118.892s
Timestamp Frames=Off
White Bal (B)=67
White Bal (R)=58
Brightness=23
Cooler Power=54
Temperature=-10
Target Temperature=-10
Cooler=On
Auto Exp Max Gain=0
Auto Exp Max Exp M S=30000
Auto Exp Target Brightness=100
Mono Bin=Off
Trail Width=3
Minimum Trail Length=100
Trail Detection Sensitivity=9
Remove Satellite Trails=Off
Background Subtraction=Off
Planet/Disk Stabilization=Off
Banding Threshold=10
Banding Suppression=0
Apply Flat=C:\Users\jsnat\OneDrive\Desktop\SharpCap Captures\flats\C8-400gainMasterFlat_2023-03-20-1122_9.fits
Hot Pixel Sensitivity=5
Subtract Dark=C:\Users\jsnat\OneDrive\Desktop\SharpCap Captures\darks\C8 30-sec400gain MasterDark_10_frames_-10.0C_2023-03-20T11_20_03.fits
NegativeDisplay=0
Display Black Point=0.03125
Display MidTone Point=0.123579833702411
Display White Point=0.998046875
Notes=
EQMOD ASCOM HEQ5/6=RA=20:35:14,Dec=+60:14:10 (JNOW)
TimeStamp=2023-07-11T01:42:33.4311038Z
SharpCapVersion=4.0.9538.0
StartCapture=2023-07-11T01:42:12.2916309Z
MidCapture=2023-07-11T04:18:13.9906309Z
EndCapture=2023-07-11T06:54:15.6896674Z
Duration=18723.398s
FrameCount=157
ActualFrameRate=0.0084fps
TimeZone=-4.00

[decay]

I'm sorry, but I'm afraid this problem indeed cannot be addressed with processing in ST . This looks like there are two different angles of that 'walking noise'. Have you rotated the camera while taking the subs?

You mention darks and flats, but no bias frames? Maybe that's read noise?

To find out the underlying reason it could be helpful to have a look at the single frames, most important one light frame. Would you mind to share one?

Best regards, Dietmar.

Edit: Could you please tell us, if you are autoguiding and dithering?

2023-07-11 17_01_05-StarTools.jpg (125.32 KiB) Viewed 19204 times

[Moonstruck]

Thanks Dietmar.
Here is a link to one light file:
https://drive.google.com/file/d/1JQK2cr ... sp=sharing

I was autoguiding using PhD2 but was not dithering. I was told that I should use "dark flats" instead of bias files when processing, so that is why i didn't use bias files. The stack I provided didn't include my dark flats though.

I am most curious as to whether the problem is on the capture side (using sharpcap) or on the processing side (using startools). I suspect it may have been during capture and I am in the process of looking at the settings. I think I may have accidentally set a capture setting incorrectly relating to the use of automatic flats or darks.

[almcl]

As Dietmar says, there are two angles of walking noise. You can see them in the screenshot below (from the Wipe module).

Dithering should help with this in future. So too would preventing, or at least reducing, image drift. That depends on your imaging and guiding set up and may be harder to achieve.

Don't think it has a bearing on this case, but I found the advice to use dark flats in DSS didn't help. You could try shooting some bias frames - they are quick to do, and then stacking with them and then comparing with a stack made with dark flats. See if there's a noticeable difference?

walking noise.jpg (189.84 KiB) Viewed 19192 times

[Mike in Rancho]

Hey John,

I can take a look later but I think the bulk of the issue is already pointed out - that is some brutal walking noise.

I had the same thing a few years ago. Exacerbated by the fact I was using a slow telescope and a non-cooled DSLR. That meant my SNR just wasn't so good, absent lots of integration and often even with, and stretching just brought all that noise - including the walking noise - front and center.

So, I had to start guiding. And if you are guiding, you might as well turn on dithering. Dither or die, they say!

Fixing whatever calibration errors are going on won't get to the underlying cause of the walking noise, though if miscalibration is resulting in excessive or improper vignetting correction, it can seem as if you have more of it. In the center around the target if undercorrected, towards the edges if overcorrected.

I believe what Dietmar meant regarding calibration evaluation is if you could upload a sample of each of the files that you fed into DSS when it was failing. Or, failing even more, I guess. So, an original light, dark, flat, and dark flat.

I don't know my way around Sharpcap, but just skimming the log you posted, it appears that some sort of dark and flat correction may already be applied? I don't know if that's just for a live stack, or is ending up in your saved lights. If so, calibrating again in DSS could result in various double-subtractions, possibly erasing much of the data.

I am not sure how to do a proper full calibration in DSS if Sharpcap is itself performing some aspects of calibration. It would have to be untangled.

[Moonstruck]

Thanks for the replies, and Hi Mike!

Mike- you are correct that there was already a dark and flat subtraction going on and that was my fault- I did it by accident. I was livestacking earlier and had the automatic dark and flat subtraction turned on for that, and forgot to turn it off when I did my long exposure imaging... therefore it was adding dark and flat correction twice when I added the calibration frames afterwards, which may have been at least some of the cause of these issues.

You mentioned that calibration frames themselves don't usually cause noise, so there must be another contributing factor. You're probably right on that too. I was guiding with PHD2 and had a very high total guiding error - something like 1.6, higher than it has ever been before. That may have been because I didn't do a PHD calibration for the scope I was using (a C8) and PHD saw the guiding calibration from the last time I did it with my Esprit 100 refractor. The C8 weighs a lot more and I can see how PHD would react differently to it than my much lighter refractor. I will have to make sure I re-calibrate in PHD2 every time I change scopes.

So to summarize, it appears that the bad guiding combined with the flat/dark correction mess were probably to blame for all this noise. You mentioned dithering. I am not sure how to dither and will have to read up on it. I am sure Sharpcap will let me do it, I just have to learn how. Or is it through PHD2?

Thanks again to you and the others for the help. Rather than posting more dark/flat/dark flat frames for analysis, I think I'll just make these changes and hope for better luck next time!

Regards,
John

[Mike in Rancho]

It'll be through both, John. Basically the capture program and PHD2 will work together and talk to each other. Just a matter of setting that up, choosing your scales, and then frequency of dithers. Sharpcap (or whatever) will initiate the dither command to PHD2 at the right times, and hold off on imaging until PHD2 signals back that it is done (settled down).

[Moonstruck]

MIke, et al:
Well I tried capturing the fireworks galaxy again last night and the noise is gone (for some unknown reason) but I now have egg-shaped stars. I was taking 4-min exposures for around 5 hrs, guided with PHD2. Not sure if it is a PHD2 issue, a mount issue or what. This would have been a decent image if not for that... anyone have any tips on what I can do to prevent egg-shaped stars next time? Image files, the sharpcap capture log and the PHD2 log are attached below. If you don't have time to look no problem; any quick comments without detailed analysis are also appreciated!

Note- I tried to get dithering to work but I'm not sure it did. I didn't see the image move at all during capture and there were no notes on the PHD2 graph saying when dithering occurred. I'll work more on getting dithering going, but for now I just want to get rid of those egg-shaped stars!


Processed file (lights, flats, darks, dark flats):
https://drive.google.com/file/d/1q3ciIf ... sp=sharing

Autosave file from dss:(lights, darks, flats & dark flats stacked):
https://drive.google.com/file/d/1VZEhiJ ... sp=sharing

PHD2 log:
https://drive.google.com/file/d/1oWgG0i ... sp=sharing

Sharpcap capture file:
https://drive.google.com/file/d/1gCIUg8 ... sp=sharing

[Mike in Rancho]

Hi John,

Well I don't know much about analyzing PHD2 logs, but looked at it nonetheless. The calibration graph seemed pretty straight, although the text indicates a lot of lost stars problems. Odd. There were also quite a few lost stars/low-SNR stars during the guiding run, though I have to say that overall the graph generally looks pretty tight, albeit with some occasional spikes.

This is broadband of course? 4-minute subs with a C8, even reduced to 70%, might be a wee bit optimistic?

Pretty long focal length, the kind for which I think most would be using OAG? Again...

The log seems to show that only one dither ever happened, right near the outset, and then never again.

At minimum, I would probably shorten those subs considerably. At least then you could toss out the ones where any guiding excursions happened.

Can you blink through your light subs? Look for any (or all) that may show trailing or eggy stars. Perhaps link a couple, one good, one eggy, if possible.

I'm also wondering if focus was not so good, but it's hard to tell. I might just be seeing things due to the stack having included some eggy and bloated stars. Inspecting single subs should give a better idea on focus. Is there an EAF hooked up? B-mask?

Best I can come up with for now. I just autostretched your stack, didn't try to process it through. Would want to double check focus first, and if that's okay, perhaps re-stack but cull the worst eggy subs and see if that makes things better.

[Moonstruck]

Mike,
Thanks for the additional analysis!

Here is a link to one light frame which shows the eggy-looking stars, which look the worst in the upper left. In the lower right of the screen they look round (or a lot better at least). After doing some reading on the subject, this looks like it could be comatic aberration (i.e, "coma"). There are tiny lines coming from the stars in the upper left if you look closely:
https://drive.google.com/file/d/1mo6aIp ... sp=sharing

If that is the case, there is a possibility that the C8's corrector plate may be out of alignment. Since the problem looks worse in the upper left then it seems like I can rule out a tracking problem. If tracking was the problem then the egg-shaped stars would be uniform across the whole field of view, correct? Just a guess... Coincidentally I took off the corrector plate about a month ago and cleaned the scope. When replacing it I may have not seated it properly... maybe if it was not completely snug it could have caused this issue due to a misalignment. Any other ideas?? I collimated it very carefully after replacing the corrector plate (spent a long time on it) with an artificial star, and though I didn't get the "airy disc," the collimation looks spot on. Poisson's spot was dead in the center just before reaching focus. Also regarding focus... I used a bahtinov mask before imaging and had a perfectly centered center spike- this looked very good, so I don't think poor focus was the issue. I have heard that focus can change throughout the night due to temp changes but I really don't think it changed enough to cause this problem.

The stars look bloated and out of focus probably because I messed around too much with the star tools modules (maybe I stretched the image too much or used the wrong tools). Still learning this software!

I decided to go with a piggy-back guide scope (Skywatcher Evoguide 50) so I could use it for polar alignment and plate solving while using my C8. With the C8's long focal length, even with reducer, it just can't beat my guide scope's shorter focal length (242) and wide field of view for both of these things! Polar alignment in particular (using sharpcap's polar alignment tool) is much easier with the guide scope. True an OAG would probably give more accurate guiding for a C8 as it sees exactly what the main scope sees, but I can achieve pretty good guiding with this smaller scope. I use a ZWO asi 174mm camera with the guide scope which gives a really wide field of view. Some may say that "flexure" may be an issue with a piggy-back guide scope on a C8 but how much of an issue is this, really?

Regarding the dithering issue... I am mystified why it only dithered once and stopped. That is very strange and I have no idea. Maybe I did something wrong here setting it up... it was the first time I tried dithering. I'll try it again next time and see if I can get it going.

That's my latest data dump. Don't feel obligated to respond - you've already spent tons of time here - but as usual your continued input is always welcome!