Recently Browsing 0 members
- No registered users viewing this page.
I've run into a bit of a strange instance when calibrating my OSC subs using my master flat generated from a white tablet screen, especially with my L-eXtreme filter. One corner seems to overcorrect using these flats, however, when I use skyflats I don't see this overcorrection and the end result looks pretty good. Whilst the answer is clearly "take skyflats", I'm not always fortunate enough to take flats first thing in the morning (weather wise, it is the UK!) so it would be great to understand what's going on with my tablet and how to avoid this issue. Details are below, but my questions are:
How can I prevent over-correction with tablet flats? Am I over-exposing them? If I change my light source, will I see this same issue if using an EL panel (e.g. like this one )or a bespoke flat field generator (like those provided by Geoptik, Pegasus Astro etc.) Is there anything in the PI WBPP 2.0 script which can help identify overcorrection and adjust the amount of correction applied?
For the tablet method, I capture my flats using the auto-exposure tool in my ASI Air Pro (it calculates the optimum exposure time based on the light source presented). The light source is my tablet display at 100% brightness, no blue-light/night time filter, and displaying this blank, white page provided by Covington on the screen. The display is large enough to cover the entirey of my Redcat 51. I attach 2 layers of t-shirt to the front of the telescope and the camera used is an ASI533. It's a small sensor, so I wouldn't expect to see a significant amount of vignetting compared to a full frame camera. For the skyflats, I used the same approach but used 4 layers of t-shirt isntead of 2 to ensure I don't end up with too short of an exposure time.
The exposure time has been adjusted to ensure the average value of the individual frame is ~30,000 ADU for a 14-bit image. For the tablet flats, this results in a 7 second exposure using 2 layers of t-shirt. For sky flats (overcast day), this results in 180ms flats using 4 layers of t-shirt to ensure the exposure time wasn't too low. The optical train had not been disturbed in this time, and both approximate exposures were determined by the ASI Air Pro auto-expose feature (I rounded them up when shooting). There were 30 x flats for each case. The tablet flats were taken at midnight, the skyflats were taken in the morning. Other than this, there was no difference in imaging conditions.
All stacking is performed in PixInsight using the WBPP 2.0 script. All settings under flat are left at default settings. The script was executed twice: the first was using tablet flats, the second was using skyflats. No other changes were made in the stacking process.
Flat Images and MasterLights
Below are four screenshot images. The top row shows debayered master flats (purely for illlustration purposes), the bottom row shows the final stack. The left side shows the tablet flats, the right side shows the skyflats. The statistics are from the master flat, pre-debayered, and show there there is a small sifference in mean values. However, the images show much brighter corners for the tablet flats, especially in the lower left where I see over-correction. You can see this clearly in the master light images. Looking at the master light which was calibrated using tablet flats, you can see a red cast over the lower left corner which I suspect is overcorrection from the flat. However, you do not see this on the master light which was calibrated using skyflats, the background looks fairly uniform.
Still sorting the (new to me), Atik 16200 imaging train as I try to shift from my trusty SBIG 8300, Mac to PC for mount control/capture and from a separate guide scope to the Atik OAG....
The camera needs to go back to Atik (awaiting the email from Vince) as there is dust inside the chamber, so this is a good time to get everything checked - ready for the autumn season.
After some imaging/testing time at the rear of Leo in the last week, I noticed on my flat frames a strange half moon light - by the dust mote (that was over-correcting the lights).
Eventually I worked out it was the screws surrounding the sensor cover window (or the 3x rounded cap screws that attach the EFW3), bouncing the light onto the back of the filter (Baader L in this example) and I suppose onto the cover window and onto the sensor. To test the theory, I opened the imaging train up and added a Sharpie pen to them. Couldn't get into the cross-heads with the pen, but with re-testing, the reflection had gone! Perhaps it would never be an issue with the actual light frames, but you never know with a bright star in the frame of a future target...?
So today, after shifting slightly outwards the OAG stalk, I addressed the stainless steel screws 'properly', by (again), taking everything apart and lightly painting a cover of matt black acrylic paint over them and into the x-heads (a bit of overspill), nothing too heavy-handed as I didn't want to glue the things in with paint! The finished effect is duller than the pic here and the reflection has gone after another round of testing.
Always something to catch us out, hey!? Why Atik can't use black screws is another matter.....
Perhaps this may help others out at some stage....
Over the past few days i've been gathering data on M31 due to the battery not lasting long and andomeda dissapearing behind a tree, therefore the mulitple imaging sessions. So far i've been out and me being me, only took dark, bias and light frames for the first 2 sessions but for the last one i also included flats... (The lights all have very slightly different settings cause i have been experimenting slightly... that being 45sec @ ISO 400, 45sec @ ISO 200 and 50sec @ ISO 100) Now DSS assinged all the correct bias and dark frames to the corresponding light frames but because i only have flats for my last imaging session it applied those to all the different light frames and not just to the last set...(and due to me moving the telescope / taking the camera off, the dust spots have obviously been moving around and that therefor dont work at all for the other light frames...) So my question: Is there any way in DSS to apply flats to only one set of light frames and if not are there any other apps with which i can do this with?
when applying the flats taken in my last session (to find out what is causing the strange diffraction spikes) with Siril, the final stacked result still shows the vignetting and the dust spots. I also did the whole preprocessing with Nebulosity, same result.
I took the flats as follows:
same iso as my subs camera and focus not touched I use a homemade flatbox combined with the a white t-shirt with Ekos took test shots till the histogram was half-way to the left checked all my flats, they all show vignetting and the same dust spots as in my subs I tried using them with and without using a bias frame, same result, the final result looks as if no flats were used.
Anybody any idea what is going on? An other question I have, will the vignetting and dust spots also show in the master flat (flats stacked)?
Thanks for your help,
Probably an old discussion but lets review it with some measurements:
The dark noise should only have a small influence on the total noise of the final image. Most noise is generated by the sky background. Under good conditions SQM = 20.4, I measure using my ASI1600MM-Cool the following noise (standard deviation) in a dark and in a light for an area where no stars are visible (local measurement using ASTAP):
Dark 1 x 200sec, σ = 15 (range 0..65535)
Light 1 x 200sec, σ = 130
The noise in the dark is roughly 12% of the light, which seems acceptable to me. That would argue for about the same amount of darks as lights. With a worse SQM, you can probably do 2.5 times less darks for each (magnitude) step. So under light polluted sky you can do with much less darks than lights.
If you are going to photograph with the H-alpha filter, it will be super dark. In a single H-alpha (7nm) light I measure a σ = 25r. Of these, 15 are self-noise and 10 of the incoming light. In good conditions and using an H-alpha filter, this is an argument to make much more darks than lights
Above for a monochrome camera. To measure with an OSC (color) sensor I think it is better to first split the 4 Bayer pixels into 4 files and then measure them separately.
Some measurements with my ASI1600MM-Cool, monochrome:
1 x 200 seconds, σ = 16
1 x 200 seconds - master dark, σ = 15
4 x 200 seconds combined - master dark, σ = 6.8 This is approximately 15 / square root (4)
41 x 200 seconds combined, σ = 5
90 x 200 seconds combined, σ = 3.8 This is a limit value that arises mainly from unevenness of the pixels. The noise will be smaller, approximately 15 / square root (90) is 1.6
STACKED LIGHTS noise (lights corrected with darks and flats):
11x200 seconds, σ = 70 (measured at a star free area, standard deviation in 0..65535 range, sky conditions could have been different)
18x200 seconds, σ = 36
18x200 seconds, σ = 40
40x200 seconds, σ = 26
42x200 seconds, σ = 30
44x200 seconds, σ = 25
58x200 seconds, σ = 20
95x200 seconds, σ = 16
Apparently the light noise decreases considerably while stacking more lights and I reach σ values up to 16 a 20. You do not want to stack these images with a single dark having a σ = 15. If you want to keep the dark noise added below 10% of σ = 16 then you need 100 darks because they give: 15 / square root (100) = 1.5 noise.
So this confirms for a good suburban site (SQM=20.4) you will need about the same amount (or more) darks then lights. For a more light polluted area you can take less darks since the noise from the skybackground will be abundant. For H-alpha work you better take more darks then lights.