Are your Flats Overcorrecting?
May 18, 2025
Table of Contents Show (Click on lines to navigate)
Introduction
I recently had First Light on both my Observatory and my new Galaxy Scope, the Sharpstar SCA260. The target was M106, and the post for that can be seen HERE.
After I gathered my first night of data, I did a limited run with WBPP to see what the Lum image was looking like. Here is what I saw:
Master Lum image with no flat cal.
Hmmmm….
Dark Vignetting? Check!
Dark Dust Donuts? Check!
Clearly, I need to do a flat calibration as part of my WBPP Process! Lucky for me, I had just shot some flats that morning. So I did another run and pulled up the master Lum flat:
The Master Flat for the Lum filter.
Nothing too surprising. The issues seen in the uncalibrated master image were seen here, as expected. So, now I can run WBPP and use those flats to clean things up!
Right?
Here is what I got when I did that:
The Master Lum image after enabling Flat Correction!
The Problem
Wait. What?
My Dark Vignetting has now turned into Light Vignetting!
My Dark Dust Donuts are now Light Dust Donuts!
What is going on here? Clearly, my flats were over-correcting!
I have been doing Astrophotography since 2019. I have shot flats for almost every night I have captured data. (I did this because I used to set my scope up every night in the driveway, and moving the gear could cause the dust motes to move around. So to be safe, I did them nightly.)
I had never run into any problem before!
Why now?
The fact that I am overshooting suggests that there is some scaling problem. But where was it coming from?
I started to do some research, and I found a couple of excellent discussions on this topic on Cloudy Nights. Let me provide you with links to those here for your reference:
General Discussion:
https://www.cloudynights.com/topic/685094-tuning-flats-in-pixinsight-using-pixelmath-process/
Using PixelMath to correct the problem:
https://www.cloudynights.com/topic/685094-tuning-flats-in-pixinsight-using-pixelmath-process/
The Fix
This suggested that an undesirable offset in the data was causing the scaling.
To calibrate lights, they are divided by Master Flats. If there were a mismatch in one or another, it would appear as a scaling problem because of this division.
However, regardless of how this problem came about, the fix is to add a constant to the Master Flats and, using PixelMath, adjust this constant to improve the scaling problem.
This simple PixelMath expression is all you need to add a constant to the Master FLat image, Just drap the triangle onto the image!
So I picked some numbers, added them to the Master Flat with PixelMath, and then reran WBPP.
Adding an offset to the FLat Master to attempt to correct the scaling problem.
With the first one, I added 0.52, the second one 0.54, and the third one 0.58.
You can see that the 0.52 is still overcorrecting - the donuts and vignetting are still light.
The 0.54 one is better - the problem has almost completely gone away - although the vignetting still is an issue. .
The 0.58 one is now starting to undercorrect - we still have dark donuts and vignetting.
This test proved to me that there was an undesirable offset that could be corrected this way.
But this interactive nonsense is a royal pain in the nether regions. I didn’t really want to compensate for the problem; I wanted to prevent it from ever occurring!
What Might Be the Cause?
So why do I even need to do this? Research suggested a few possibilities.
1. I discovered I forgot to cool the camera for the Flat Series. This could make the Flat Darks look different than the Darks and cause an issue.
2. The LED panel, even at its lowest settings, caused very short exposure times with broadband filters—around 0.2 seconds. CMOS sensors can have very different noise profiles with short exposures, and the guidance is to make sure they are longer. Again, they can make the Flat Darks look different from the Darks, causing problems. I saw one example Adam Block did, where the Flat Darks had much higher signals than the Darks - thus causing the problem.
But in my case, I see no smoking guns.
The average Flat signal is about 0.42. - about mid-range, which is good.
The Dark Flats are almost the same average as the Darks, so there is no obvious problem.
So I kept digging.
The Smoking Gun is Found!
I kept looking at things, trying to figure this out.
Finally, I started looking at the FITS header file and the metadata for the files concerned.
And there I found a problem!
The Darks and Flats were shot with a camera offset of 10.
The lights were shot with a camera offset of 50!
This offset difference would act as a scale factor and mess things up. I was pretty sure this was the root cause. But how did this happen?
I was in the process of setting up NINA for four new microcomputers for telescope platforms - all at the same time!
I had set the camera offset to 50 with my NINA Sequence Program.
However, with the NINA FlatWizard, I never set the offset explicitly, so it defaulted to 10, which was the value that the ZWO native driver defined.
Proving It
The very next day, I reshot all of my Cal files and made sure that the FlatsWizard in NINA was set to the same offset as used with the Lights. Later that day, I reran the same subset of Lu images with the new Cal files and found that things were vastly improved!
The Lum Master witht he corrected Flat files.
You can see that the vignetting is gone and almost all of the dust donuts are gone!!
However, if you look closely, you will see some residual rings in the upper left corner of the image.
These have an “embossed” look. I don’t think this has anything to do with the offset problem.
This can happen if your filter wheel is not accurately positioning the filter for each exposure.
If you read my post on setting up the SCA260, you may remember my self-inflicted problem with my EFW ( I put the wheel into the case backward—DUH!). Things started working when I flipped the wheel around so it was installed correctly. What I did not do was have the EFW driver run a new self-calibration, which could explain the positioning error. I will do that before the next imaging project.
Conclusion
This seemed to settle the case of the Overcorrecting flats!
Since this caught me by surprise, I thought I should share it in case it might help someone else struggling with the same problem.
In my case, it was easily caused and easily corrected when found what has happened, but the finding was not so easy. Hopefully this will help you should you ever have a similar issue!
