2026-10-09 APP 2.0.0-beta48 has been released !
This is mainly a bug fix release for the reported bugs in beta47. In addition it has a significant User Interface performance improvement noticable when you need to process 1000s of images in APP.
2026-10-03 APP 2.0.0-beta47 has been released !
This is a very big release... many code optimizations/rewrites, many parts of APP are much faster and more precise, especially star analysis and registration are much faster ! Big mosaics will go much faster 🙂
And we introduce a new preview filter, which includes the new Adaptive Deep Sky Stretch and a General Levels Stretch, this has been long over due. The old preview filter (the panel on the right side to stretch and preview your data) has not been updated for a couple of years and it is a critical part of any APP session.
Adaptive Deep Sky Stretch or ADSS is a much more intuitive stretch algorithm. It is also color preserving (which is a great new addition in itself ! ) which means that the highlights are no longer bleached, color is maintained from the linear data while stretching. You can simply stretch your data using the sky background level and signal width sliders which work much easier and more intuitive. You no longer need to fiddle with the old complicated sliders with zoom buttons. All the zoom buttons for the sliders are made redundant. And you can enter slider values in the slider value fields yourself. I will make a youtube video in the coming days to explain and fully introduce ADSS. Once the video is ready, it will be highlighted on the forum.
RGB Combine upgrade !. The RGB Combine Tool has been rewritten mostly. The tool is faster and easier to use and most importantly, the Luminance slider to inject a luminance channel or channels into the RGB composite is now working correctly. It no longer bleaches the RGB colors. Combined with the new ADSS preview, you will get much better and easier great composites with great color! I will also explain this in a new youtube video.
Hi Vincent,
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!
Regards,
Anne
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!
@vincent-mod
I have made a small testset and reproduced the issue on that set. I am sending this set now, together with screenshots of the settings and outcome and a short document describing my analysis of the issue.
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?
Hello Vincent,
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.
Regards,
Anne
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.
