2023-01-19: APP 2.0.0-beta13 has been released !
!!! Big performance increase due to optimizations in integration !!!
and upgraded development platform to GraalVM 22.3 based on openJDK19
We are very close now to releasing APP 2.0.0 stable with a complete printable manual...
Creating a Master Dark Flat - what am I doing wrong
I often take flats down around the sub-1 second mark (let's say 0.1 sec).
I have created a library of "Dark Flats" which include flats for 'normal' exposures (e.g. 60 seconds) and flats for my dark flats (i.e. the 0.1 sec flats).
I have just noticed (after a couple of years of serenely assuming that everything was working properly) that the average ADU for the short expsosure Master Dark Flats are way too high (but the 'long exposure' master darks have the average ADU I would expect - quite low).
As exposure times go shorter, the average ADU in the APP generated Master Dark Flats is rising (and it is way way higher than the input files were). e.g. for the 100 ms Master Dark Flat I have an average ADU of 38,078 whereas the average ADU of the input files was only 1917 (Min of 1732, Max of 3360)
So surely this is wrong? Using that Master Dark Flat is surely going to mess up my calibration of the Flats?
If so, what am I doing wrong? Happy to upload my files if that helps
(I should say, this is the same on old and recent calibration runs, and the same on different cameras etc - it's just that I only JUST noticed it)
Shooting flats at 0.1 seconds is not a good idea anyway, some sensors are not behaving properly at very short exposures, which may result in what you're seeing. We advice a minimum of 0.5 seconds, but preferably around 1-2 seconds per flat. Same for the darkflats indeed.
I have heard that.
However, although I mentioned 0.1 sec in the post above, that was just to emphasize that this happens at the shorter exposures. Looking at my library of master darks, anything below 10 second exposures is showing this problem. So when I say "short" exposures, effectively that includes images in the range 1 sec to 10 seconds (as well as shorter)
The individual subs at those exposures seem to be "normal" (i.e. their histograms are normal looking, and have average ADUs which are "very low" as you would expect. Nothing seems odd about the images at least). So if the fits files seem to be completely normal, then why would stacking them suddenly make them create a Master file which has much much higher average ADU (for some examples, it looks more like a flat frame than a dark frame!)?
I am not able to upload my fits files to this thread (the system is saying you cant upload that file type here) but I can send you a couple of the 2 second fits, and the master dark they created if that helps? (even stacking just 2 of them together creates the same weird output as stacking tens of them).
I have 3 example files here, of a 2 second Dark, where the stacked MDF file has an average ADU of 3593 (min=1681, Max=24472 (!)). It was made up of the 2 fits which each have an average ADU of 766 (min=256; max=5280) and 766 (Min=192; max=5200)
So the average ADU of the 2 second MDF is 4x that of the individual frames (for this example)(and note: shorter exposures create even greater multiples - e.g. 20x or more). And the Max figure is much higher than the component max figures
I am able to upload a text file though, so I append the output of the console, for you
Thanks for any insight or help!
Digging into this a bit more
I am using the ASIAir to capture my files. ASI supply a free suite of tools for stacking - so if I use the ASIDeepStack module to stack the exact same files, then it comes up with Master Dark Flat file with an average ADU of 766 (min=360; max=5240) which is basically exactly what I would expect given the input files
I appreciate that ASIDeepStack isnt doing many of the complicated things that APP is doing, but something must be misconfigured for me (or something) in APP.
I wondered if updating to the latest APP version would help, so I updated from 1.083 to the current 2.0.0 Beta6 and did the same stacking on the same 2 files. It still does the same thing (though this time, for some reason, the average ADU is slighty different (3578 vs prior 3893) (the max and min are the same values though)
Mm, to really say anything more about this I would need the data to look at, would you be able to upload say 10-15 of the calibration frames? Maybe also add 10 lights and 10 of the other calibration data, just so we have that complete.
I just uploaded 15 x 1 sec Darks and the MDF that APP creates from them (as you can see, the average ADU is a *lot* higher than any of the component files)
I also uploaded 15 x sec flats (dont laugh at the quality of them!)
And I copied pasted the console output into a text file
When you say: "and 10 of the other calibration data, "- what do you mean?
I meant, any other data you may have. 🙂 I'll have a look at these.
Ok, so I'm not seeing an obvious problem actually. And talking to Mabula, it would also not make sense (like you're noticing) for the ADU to be super high compared to something else. And it definitely doesn't make sense to have this not happen at longer exposures. So my question to you would be; are you maybe looking at the files while stretched? Where do you get the mean ADU from?
Thanks Vincent, and apologies for a delayed reply (I was out of the country).
>I'm not seeing an obvious problem actually
Do you mean that you arent seeing the mean ADUs that I am seeing?
For the MDF file I uploaded, I see an AVG ADU of 453 (compared to one of the 10 files it was created from having an AVG ADU of ~47). I am using the ZWO tool (ASIFitsViewer) to show me these values.
If I stack the individual files using ASI DeepStack and then view the stacked MDF in ASI FitsViewer it has the mean ADU you would expect (i.e. around 47 ish).
But if I stack the same individual files using APP and then view the stacked MDF in ASI FitsViewer they have the 'far too high' mean ADU value (i.e. 453).
So as the only thing which is different is the stacking software, I am assuming it isnt the viewing software. But do you recommend a different way / software to see the average ADU of a file? (is there a way to use APP to see these values?)
Yes, so an increasing ADU is very weird and I suspect the stacker is doing something different, maybe also in the way it views the ADU. I have no experience with the ASI tool unfortunately.