31 May 2021: APP 1.083-beta2 has been released ! APP 1.083 stable will follow soon afterwards. It includes a completely new Star Reducer Tool, New File Saver Module, Improved Comet registration and much more, check the release notes here!
Flats not applied, MasterFlat applied - bug?
I just recreated this situation that I had encountered before. I just had to be sure I could reproduce it. Here's the issue:
I normally use masterdarks, masterdarkflats (as my flats are standardized in exposure time) and a pre-produced BPM. While integrating with the mentioned masters and with the individual subs for the flats for that session (since that is something that changes with a new imaging session), the flats are NOT applied in the result. The workaround is to first produce the masterflat and only then integrate the lights with all the calibration masters. Then the flat IS applied.
I guess this is a bug...
For completeness sake: I recreated this with the Ha_OIII - extract OIII algorithm. As far as I remember, I also had this with the "normal" RGB algorithm, but I am not sure.
Looking forward to the next release!
That is an interesting one as it should work. Darks, as well as darkflats and bias shouldn't change all of a sudden and can be applied to new flats. Do you want to upload some of the flats, lights and the master calibration files for me to reproduce this?
Go to https://upload.astropixelprocessor.com and use upload2 as username and upload2 as password.
Create a directory named “annehouw-masterissue” and upload in there. Thank you!
Excellent, thank you. I'll download the data shortly.
Ok I think I understand your issue a bit better now I read your (excellent) uploaded explanation of what you do.
So a couple of things to clarify;
1. Not selecting the "create masters", will indeed not create a masterflat and thus it doesn't get applied. This is to be expected, if you already loaded in your previous Master-Bias and Master-Dark, no additional masters will be created, just a masterflat.
2. If you load in a masterflat as well, then yes, that will be applied. It's all about having masters, correctly corrected. If those are present, they will be used.
Does that make sense?
Thanks. Let me first state that there must be much bigger fish to fry in Mabula's pan 😉
As for it making sense? Sort of, but it is not the most logical thing in the world for the software to do.
What I would expect the software to do is that if you load flats it assumes that you intend to use those flats for calibrating the lights (otherwise, why load them?). My assumption was that APP would still CREATE a temporary masterflat in the background to use in processing, but not SAVE this as an actual file on my disk. It is APP's "saving being the same as creating" that brought me off course.
I am now reading the tooltip on this switch as: "Unless you are only making a Bad Pixelmap", you MUST enable this function. If you disable this function, calibration files (darks, flats), even when loaded, will NOT be applied to your lights".
Not a big deal, but good have as much clarity as possible.
Ok, I see how you could read that differently indeed. Might be interesting to maybe change something small about that to make it a bit more clear. Loading in data like flats and having this option is so the user still has flexibility in what he/she wants to do. You may just want to create an integration without first for whatever reason. Things like this might be something we could put in a settings window or something, so you can make APP do what a specific user expects. Mabula is working on settings at least. We will likely add more and more settings when that is implemented.
Thanks for letting us know this, always good to see what others might do differently. As developers this sometimes is missed as you then know what to expect. 🙂
All fine here. And +10^6 👍 for a user-settings configuration file.