15th Feb 2024: Astro Pixel Processor 2.0.0-beta29 released - macOS native File Chooser, macOS CMD-Q fixed, read-only Fits on network fixed and other bug fixes
7th December 2023: added payment option Alipay to purchase Astro Pixel Processor from China, Hong Kong, Macau, Taiwan, Korea, Japan and other countries where Alipay is used.
@stastro yep, that was my teaching, 1/3 to 1/2 way up.
now i do 2/3 - 3/4 , as long as max adu is no more than 60k, as Vincent said, no clipping at top end.
made a world of difference, on normal broadband, but especially when using LExtreme filter as well.
might just be my imaging train , who knows, but defo worth a test.
@andybooth I am acquiring 45K flats at the moment to see what happens, strange part about it is that the same camera on my previous scope which was a SharpStar 15028HNT worked well at 22.5k flats, but this 20032PNT clearly does not.
I presume that since you are using the L-eXtreme that you are using an OSC? I moved back to Mono from the ASI6200MCPro (Which I still have sat here), so I am using the ASI6200MMPro with Baader CMOS Optimised filters, again worked fine on the 15028HNT at 22.5K ADU
Unfortunately all ADU value produce a very similar result, Left is 45K, middle is 29.5K and right is 22.5K
Ok, stick with the 45K at least. 🙂 Maybe I missed it, but how are you taking the bias/darkflats, how fast are the exposures there?
@vincent-mod good point on exposure.
i need at least 0.75 secs, and usually best for me is 1.3secs for flats.
Yes, that's also because some new sensors don't behave linear in the very short exposure ranges. So we recommend at least 0.5s per bias sub and 1-2s for a flat at least..
L = 3.9s
R = 5.22s
G = 5.17s
B = 5.56s
Ha = 82.98s
OIII = 24.14s
SII = 133.05s
Dark flats are the same exposure, temp and Gain level
Yes I already new about the issues with sub second exposures for flats which is why I always aim for >2s, NB can't do anything with, that is with panel up at 100%, Luminance panel is at 1% and RGB around 40%
Allright, then I think we need to see the data to be able to check for other things. If you want, please upload like 5-10 subs per filter and the flats for them, including 10 bias/darkflats, 10 darks.
@vincent-mod Dark will be masterdark anyway
I wil upload
1x Master Dark
1x BPM
10x Light frames for each filter
10x Flat frames for each filter
10x Dark flats for each filter
Do you want them in a zip / rar file?
All files uploaded, I created two subfolders, one for flats, the other for dark flats
Thanks Simon, I'll download the data today and will try to check today or tomorrow (it's a birthday of my kid here so please allow for a day or 2). 🙂
Checking it right now;
I appear to see stars in the masterdark, can that be the case? If so, that might influence calibration for sure. You do need a bias signal for the lights as well, so that should come from a proper dark or a bias. I'm also wondering a bit if the over-correction is from the flats or you have residual light pollution actually coming from below.
I also say this as the vignetting seems properly centered and is all around, but the light pollution model (after integration with the flats), doesn't show clear overcorrection all around.
Checking it right now;
I appear to see stars in the masterdark, can that be the case? If so, that might influence calibration for sure. You do need a bias signal for the lights as well, so that should come from a proper dark or a bias. I'm also wondering a bit if the over-correction is from the flats or you have residual light pollution actually coming from below.
No chance of stars in the Master Dark, this is the Master Dark - Stretched of course
So I re-aligned the optics last night and did some imaging, new lights, new flats and after my post processing script has ran which also includes an Auto Background Extraction, this is the result:
So clearly it's not an LP thing, as the LP would not have the shape of vignetting for sure, it would be more of a gradient in a specific direction
A contour plot on each light stack clearly does show an LP Gradient though
Red:
Green:
Blue:
Lum:
After an ABE on each of the Light Masters, you can see that the light object is not in Blue at all
Red:
Green:
Blue:
Luminance:
The fact that it exists in Red, Green and Luminance, but not in blue indicates that it must be a light source that is only affecting Red and Green wavelengths, which of course Light Polution typically affects Green, and sometimes red, so you might be onto something with the light polution theory
Yes, because normally, when you have flat over-correction, you'd see this happen on the dark parts of the vignetting, they all turn brighter. And I noticed in your case, it's only on the bottom and that almost can't be due to flat over-correction.
Regarding the masterdark you uploaded, this is what I saw:
Zooming into a region of what I think are stars:
If you're indeed taking darks during the night on the scope, these must be stars. They cover an area of pixels, not just 1 which would be a hot pixel.
@vincent-mod All my darks are done with the scope covered and the observatory closed, so this is strange indeed, and I just looked at what you are pointing out and the shape / size is repeated where you see this anomaly, in other words all the anomalies look the same. I do not have the dark frames any more as I usually discard them when making the master dark, might re-run the darks again
Also just some insight as well, makes no difference whether my flats are 22500, 29500 or 45000 ADU, they all produce the same resulting stacked image, I think it helps that my camera is true 16-bit too, as I know certain things need to be taken into account when using 12, or 14-bit ADCs versus true 16-Bit
Darks are correct, her's a zoomed in of a current 60S dark single frame, stretched of course
Mmm, well, to us that dark does not look correct actually. Unless it's a type of glow we're not familiar with. Those bigger spots are not normal hot pixels anymore.
Just as an extra check, how do you store your data? You're not working on external disks or disks which have a FAT32 system right? Or something like having the work-directory for APP, being on an external drive?
@vincent-mod All my files are stored on a NAS using EXT4 across a 10G link, my temp location is always my local NVMe drive as I want the fastest processing possible with my 18 core system 😀
Mmm, well, to us that dark does not look correct actually. Unless it's a type of glow we're not familiar with. Those bigger spots are not normal hot pixels anymore.
I checked back on my ASI6200MC Pro as well, my master dark contains the same artifacts (but in different places), so perhaps this is just some camera chip anomaly, have asked ZWO for comment
@stastro I checked the master dark of my ASI6200MM and it has this too. This is zoomed in on a random part
and this zoomed in on one of the "dots"
@wvreeven So it must be "Normal" then 😀
Have you tried platesolving your dark frame 😀
Fascinating! I've never seen that with a sensor. Ok, well then I guess it is normal. 🙂
So I wanted to close the loop on this one, after some extensive investigation, it turns out that the scope was picking up some stray light, adding a dew shield to extend the tube by around 5 inches has eliminated the issue, the following image was processed using my existing flats at 22.5K ADU (Which is what I was always using), and I have tried with 29K, and 45K ADU flats and the resulting image is the same. I suspect I will have to re-do my flats with the dew shield though for completeness and to tidy the image up further.
Ok now this is bizarre. I moved to the M68 connector on the telescope due to the light cone for a full frame sensor at the M54 connector being 61mm, so much larger than the M54 connector. So now my flats are a hell of a lot better, M68 on left, M54 on right
However, I am back into a situation where I have over and undercorrection of the flats, here is an example:
I seem to be getting Overcorrecting on the left, and undercorrecting on the right, the above image was with flats with a mean ADU of 29500, here's the same image with flats with a mean ADU of 22500:
And here's the same stack with no flats applied:
All images have had a standard Auto-STF applied