StarTools

It's typical for me to be able to begin taking exposures of my target DSO before the Sky Background is completely dark. When it comes time to stack the images, the registering process in DSS shows me a Sky Background value which is directly related to how dark the sky has become. It is common for this Sky Background value to be slightly different for each image which causes me to choose what range of Sky Background values are acceptable. I always try to use as many images as possible only rejecting the obviously bright ones. I deselect RGB Channels background calibration. I select Per Channel Background Calibration.

Do you have any advise as to how to deal with Sky Background. Staying up until dawn is just not in the cards for me.

Peter

Hi Peter,

Using frames shot under different lighting conditions will have an impact on a number of variables in your stack. For example, the noise component of elevated non-celestial signal will make a frame with elevated non-celestial signal noisier, even after modelling and subtracting the bias. It the same reason why shooting under light polluted conditions will give you a noisier data set after subtracting the light pollution, than shooting under dark skies; the light pollution's noise component is still in there.

It really is best to wait until at least astronomical twilight has passed and night commences (e.g. the sun is 18 degrees below the horizon). For the exact times for your location for each day of the year, have a look here.

I wouldn't worry to much about slight variations in Sky Background, unless they are severe. Is the Sky Background variation - after astronomical nightfall - a clear curve, steadily dipping towards the end of your imaging session?

You could look at the application here, https://play.google.com/store/apps/deta ... c&hl=en_US to find out when it get's dark.

I have put together a PDF document that illustrates what happens to my data when I use the Per channel background calibration feature in Deep Sky Stacker. It really alters the data and, to me, it explains why you caution users about using it. The PDF also describes a method I came up with which tries to respect the original pixel values and their noise profile by simply offsetting them. If you get a chance...have a look.

Regards,

Peter

Link to my PDF document
https://www.dropbox.com/s/slxa5by99x7zb ... n.pdf?dl=0