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.
@Mabula-admin
You know I've been using APP for many years and in my opinion it is by far the best stacking program out there. However, there is always room for improvement.
What I wish to see is a much faster and smoother way to load images, lights, darks and flats. It should be possible to load all of the above based on a folder structure. The attached image below show the folder structure I use for another stacking program. All I have to do is to select the target folder (or any one of the combo folders) and everything is loaded in about 15 sec.
Here is some explanation to the folder structure:
1st level: The target name, obviously.
2nd level: The combo are my two telescopes/cameras. This folder level would substitute sessions 1 and 2. (The combo word does not need to be there, and if only one telescope/camera is used this level could be skipped entirely if the user so wish). On this level the user would normally locate lights, darks, flats (and dark flats/bias as required.) A folder containing the BPM could also be here if already created.
Since there is already a routine in place within APP to differentiate between master files and non-master files it is probably not required having to define this at folder level. However, having to do so would not be a hassel.
3rd level: I prefer to let NINA create a new lights folder for each night, but that would be entirely up to the user. There is actually no real reason to do this except if the user needs to create new flats/dark flats for each night. If so the flats/dark flats folder must be created at this level. In this case each date (folder) would be a new session to keep track of which flats belongs to which lights. Personally I would have liked to see the folder name instead of session 1, 2, 3 etc. in the final integration.
Finally, everything is grouped on combo (if created), filter and sessions (if applicable). Regarding filter names, in the program where I'm using this folder structure B, Blu and Blue would be interpreted as three different filters. It would be the users responsibility to make sure that a filter is named the same throughout.
If anything is unclear (probably) I'd be happy to elaborate.
Note that all of the above is about loading images and calibration. It will not affect the rest of the stacking process.
Please forgive this very lengthy, detailed proposal. I hope you will consider putting this on your "to do" list. It would make APP even more attractive.
Â
Hi Heno @heno,
Thank you very much for your request and your nice compliment, and I fully agree, there is always room for improvement. I will definitely add this to a new issue on our ToDo list 😉 I also want to add to this issue that APP should use the FRAMETYP keyword that indicates LIGHT, DARK etc.. that is stored in FITS files by several capture packages. Then even such a folder structure would not be fully needed I think.
I will try to implement it after the 2.0 stable release.
Mabula
Â
@mabula-admin I'm so glad to hear that you agree and will add this to your to do list.
Regarding use of the FRAMETYP keyword, I fully agree. Those should of course be used when present. That would also eliminate accidental misplacement of files in the various calibration file folders. I will probably still keep this structure as it gives me a simple overview of which files were used in the calibration.
The combo (scope/camera) level would still be needed for those of us that is imaging with two combos at the same time, even if they are identical. So some flexibility in the loading process will probably be needed. But let me not jump to conclusions. 😉Â
Will be looking forward to the first test.
Hi Heno @heno,
Great, I realize that me need to make APP easier and faster in this regard as well, so we will definitely work on it. But please note, we first need to finish the work for the 2.0 stable release with save/load whole projects with their settings 😉 after which other new features and improvements will be implemented.
I have opened a separate issue on our list with your request and the IMAGETYP keyword (I mentioned FRAMETYP earlier, it should be IMAGETYP) and it will stay high on our todo list.
Mabula
@mabula-adminÂ
That is OK with me. I was not expecting you to drop everything else and start working on this. But I will be impatiently waiting. 😆 Â
Frametyp, imagetyp, whatever. I understood what you meant. 👍Â
Helge
