What Could Be Causing This Random Noise All Of A Sudden?

The reason is PRNU or otherwise known as not having done a proper flat-fielding (or none at all as it looks likely from the pictures you posted) of the raws (plus potentially other issues such as not removing darks but is a lesser issue). Applying proper flat field with the proper technique is VITAL in data reduction as applied in AP.

David Koslicki:
Agreed that it's likely a calibration issue: the dust motes in the second shot in particular lead me to believe this. The fixed pattern noise could also be a problem with darks or biases. Is the "autorotate images" setting on the DSLR disabled? If not, there's a potential this could cause calibration issues, depending on what program you use to stack your images. 

Also, what program are you using to process your images? I've had a few images turn out like this when I was using DSS & photoshop, but the problems went away with a combo of better calibration on more sophisticated image processing software (that can do thing like background extraction, LP removal and the like). If you're interested in seeing if stacking/processing is contributing to it, I'd be happy to give a go at processing your raw subs + calibration frames.

I hadn't thought about the rotation of the frames, I wouldn't think this would matter as DSS obviously rotates them when stacking; there could be a handful of rotated frames after the meridian flips. To be honest I hadn't stacked any darks with either data set only because while I have collected multiple sessions of darks recently in the morning after my imaging session are done, I'm not entirely sure how I would match them temperature-wise with my light frames. 

This is what my stretched master flat looks like and it definitely is evident that the same dust motes appear in my stretched version of M42.



Please feel free to stack and process the data yourself! I'm very intrigued to see if you can produce a different result. 

https://drive.google.com/drive/folders/1Hghv61Dc_iaERIC2OAp3zSLGDxiF0G9m?usp=share_link

My workflow is that first I'll import the raw files into Adobe Camera Raw and set the white balance to align all histogram channels, then I'll apply lens profile correction for my lens and last I'll modify the exposure to center the histogram peak around the 1/3 point if not already (not sure if this accomplishes anything). After making all these adjustments in camera raw I'll then export to .DNG into the "Lights" subfolder in my DSO directory and stack these in DSS.

Fabian Butkovich:
My workflow is that first I'll import the raw files into Adobe Camera Raw and set the white balance to align all histogram channels, then I'll apply lens profile correction for my lens and last I'll modify the exposure to center the histogram peak around the 1/3 point if not already (not sure if this accomplishes anything). After making all these adjustments in camera raw I'll then export to .DNG into the "Lights" subfolder in my DSO directory and stack these in DSS.

Don't do any of that. Just use the workflow provided with DSS using only the raw calibration and light frames.

Fabian Butkovich:
@Jonny Bravo I don't take these calibration frames, I was under the impression that flats and darks alone are good enough, and darks themselves are sometimes redundant if the stacked data doesn't have much sensor noise to begin with. I didn't know that flats depend on biases and flat darks.

Flats depend on either a bias or a flat dark. It's in the math. A simplified equation for image calibration is:

(light - dark) / (flat - bias)

A light has all of the signal you want, plus the dark current, bias, optical imperfections, vignetting, etc etc etc.
A dark has the dark current plus the bias
A flat has the dark current, the bias, the optical imperfections, vignetting, dust motes
A bias has the bias

So, looking at the equation, the numerator has subtracted the bias and dark from your light (since the dark contains both bias and dark). If you do not include the bias (or flat dark) in the denominator, then you're dividing by a flat that still has the bias. This will lead to incorrect calibration. You _need_ to get rid of the unwanted signal from that flat frame.

I won't get into the whole bias vs flat dark debate - it's been done ad nauseam .

You really do need to subtract the bias(or flat dark) from the flat as Johnny has suggested is because the bias can be significant. A zero exposure time subframe on my 294MM, at Gain 120, has an ADU level of about 1600. If you are aiming for a flat ADU level of ~20,000, you are adding a nearly 10% error when you are calibrating -very simplistically, you are dividing by 20,000 when you should be dividing by 18,400. Subtracting either a bias or flat dark (which contains the bias) assures that you are not introducing this error and calibrating correctly.

Again from memory, but I think I didn't have the banding issue at first using 800, but don't have any guess as to why it wouldn't be an issue right from the start.

FWIW, I just found an old Astrobin thread ('DSLR Exposure Time') where I asked about the banding issue and at that time, reported it as 'intermittent' and Arun, maybe you remember replying:

"Scott - I think the reason that banding is ISO dependent has to do with the way Canon sensors are constructed. There are two components to read noise - the noise from the sensor itself and the noise introduced during analog to digital conversion. The latter is quite significant. The higher the ISO, the more the signal from the sensor is amplified before the A-D conversion is done, and hence the lower the contribution from the A-D conversion noise. Generally for Canon sensors ISO1600 and up seem to be sweet spots, though you lose one stop of DR for every doubling of ISO beyond 1600 for older Canon cameras and 400 for the Mark IV.
I have used and continue to use on occasion, a Canon 5D Mark IV (unmodified). I would always get one or two very strong bands, regardless of ISO. Using darks without biases helps get rid of them."

Cheers,
Scott

For the original poster - if using PixInsight, it has, or used to have, a Canon Banding Reduction script, since this banding problem was so prevalent in Canon cameras. It would be worth trying to use it to see if it eliminates the banding. The script needs the bands to be horizontal where they are vertical here, but that is easily addressed by rotating the image by 90 degrees before applying the script.

Arun H:
For the original poster - if using PixInsight, it has, or used to have, a Canon Banding Reduction script, since this banding problem was so prevalent in Canon cameras. It would be worth trying to use it to see if it eliminates the banding. The script needs the bands to be horizontal where they are vertical here, but that is easily addressed by rotating the image by 90 degrees before applying the script.

Is not a banding issue here, at all. It is an issue of bad data reduction. I had a check at their data and for starters the flats don't match the lights. No bias/dark flats/darks. The average value of the flats is way less than recommended and so on.

Fabian Butkovich:
I thought that flats can be applied from different sessions to any lights? as long as the focal length and focus stays the same which in my case hasn't changed hardly between data.

For DSLRs this is very much *NOT* recommended as the dust motes tends to move quite a bit from time to time when the camera is powered down. The problem with your data set is that the flats should really be, on average, having a mean value between 1/3 to 1/2 of the total dynamic range at the same ISO of the lights and from what I can see they are nowhere near.

As many have said before me, getting the dark-flats or biases and subtracting their master file from the flat lights is key to a proper data reduction otherwise all bets are off that you will end up with a properly flattened stacked light, which I suppose is one of the problems you see in your images (and this includes the M33 shot too).

I would agree that it looks like a flast/dark flats issue.

FWIW:  you are also not cropping your stacked images before processing them to get rid of stacking artefacts.  That, in itself, will also make your post-processing worse..

Here's the best I could do with your M45 image.  I'm sure others could do much better.:

Stuff I did:  

* Croppoed out the stacking artefacts
* Extracted stars with StarXterminator
* Used automatic backgroud extraction to get rid of the worst of the background colours
* Used heavy NoiseXterminator on the starless image (probably too much)
* Applied a range mask on the starless image so that I could then use curves to dial out the saturation of the background and darken it (probably too much)
* Had to apply convolution on the stars to get rid of the donuts
* used PixelMath to recombine starless and stars

This was a very quick and dirty attempt to get something out of a very noisy jpeg image, however with careful post-processing on the raw data you may be able to get something a lot better.

@Fabian Butkovich 
Hi Fabian, 

I gave a quick go at processing your subs, and wanted to share my observations: 

1.     Given this is a multi-night imaging session, your framing is rather bang on! I recall when I was using a DSLR, my stacking artifacts (from non-perfect framing) were a lot more than yours. So how ever you are going about the plate solving etc. keep at that.

2.     There were a fair number of images that had guiding errors, wind, vibrations, or the like that caused the stars to smear. I blinked through these, but instead of manually finding the best frames, I ended up just using AstroPixel Processor’s (APP) quality feature to select the best 50%.

3.     As has been said frequently here, the flats and darks/biases are a must. APP didn’t like the flats at all, so this stack is just of your lights. Note that it’s more important that you use darks, rather than omit that step because the temperature might not be “exactly correct.” Close enough is better than not at all, in my experience at least. Same with lights: better to get most of the motes than none of them.

4.     You may consider shorter exposure times. Even without any stretching at all, the core of Orion is already blown out/saturated. Shorter exposures would allow you to recover detail in the core, and wouldn’t appreciably sacrifice detail elsewhere.

5.     As mentioned here before too, you don’t want to fiddle with/change your subs at all before stacking them. Differences in illumination issues (eg. transient light pollution) and the like are post-processed out or handled by the outlier rejection of stacking. Trying to fix them pre-stack plays havoc on the stats/algorithms of the stacking process. 

My basic processing steps were:

a) use APP to register and normalize (advanced normalization) the RAW *.cr3 files

b) blink through to get an idea of the % of good subs,

c) stack with a quality cutoff of 50%,

d) use the light pollution tool (dynamic background extraction/neutralization/calibration all in one),

e) calibrated star colors based on an adaptive black body & extinction model,

f) removed the stars with Starnet2,

g) ran Topaz Labs denoise AI on the starless image (severe noise, all settings set to 0/100 except noise removal 4/100, then set opacity to ~80% in PS),

h) used photoshop to add back in the stars and do a bit of cropping, rotating, sharpening, histogram fiddling, etc. Not much could be done to save the blown out stars, hence the suggestion for shorter exposure time. 

FWIW, I found my images improved significantly when moving from DSS to APP. I don’t know if it’s more sophisticated registering/normalizing/stacking algorithms, or what, but you might consider playing around with different software. APP has “multi-session imaging” so you can match your darks & flats to each night (i.e. take flats before imaging, darks just before bed, and calibrate each night’s subs with the corresponding calibration frames).
Note: I have yet to “bite the bullet” and learn PixInsight, so I can’t say much on that front. 

Here’s the image: https://www.dropbox.com/s/b29lw6q1hzdnxan/For_Fabian-RGB-session_1-St_starless.jpg?dl=0
 And here’s the PSD file: https://www.dropbox.com/s/9mrdapgsjs963qn/For_Fabian_guy-RGB-session_1-St_starless.psb?dl=0 

tl;dr: the lights are rather good. You’ll likely be pleased with proper calibration, reduction in exposure time (and/or ISO), and alternate processing.

Fabian Butkovich:
I recently downloaded a free trial of PixInsight to see what the hype is about but it's definetely not something that's the most user friendly from first impressions.

I thought that about Pixinsight at first, but I persevered for a few days and it ends up being very intuitive.  Try working with WBPP as that is the nearest thing to DSS and you will soon get used to it.