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.
I have run a stack of 400 frames through APP. I have manually flipped through every frame and marked the worst ones before stacking. I wanted to see if APP came to the same conclusion as I with respect to frame quality. I have no idea how the various columns are calculated through the processing, but I find the results surprising to say the least.
I have sorted the files on all the relevant result columns and made a copy of what APP claims to be the best and worst frame in that particular sort. Which sort and best/worst frame is included in the file name. While some of these seem reasonable, some do not make any sense to me at all. I can't help asking the question: Are these calculations robust?
Â
They usually are yes, but I can imagine that in this case the calculations become a bit hard to make. The quality overall isn't good with the amount of background versus signal and especially when you get close to the background with the signal, it can get tricky. You can always decide to manually throw out data, the quality score is something that's being update during processing based on the info it receives out of each step. Star shape and things are included in there and it can be that some of the frames with a lot of pollution but still very nice stars, could get a higher score.
I realize that calculating these tings are probably not easy and this test has showed me that I need to change my routines for selecting which frames to stack. Previously I have mostly checked the quality column and if the 2-3 worst frames were acceptable I have assumed that the rest were too. This is obviously not the case. (It probably is if you have "perfect" data.)
I was not initially aware that these frames contained a lot of clouds, but when I started developing the stacked frames I saw that something was not right. Reloading everything to APP and flicking through the files soon revealed why. And that's why I did this test.
I suggested in a post a long time ago that APP should have had a selection criterion facility whereby one could set criteria values for each of the calculated columns and have APP exclude (uncheck) all the frames that would not meet that criterion. Now, more than ever I think this would be very useful.
Yes, a more fine-tuned selection criterium may be nice to have, as well as flipping though images faster. Mabula is aware of this and wants that to work in later versions. You can, based on quality, always select to integrate 90% for instance, which filters that automatically. Still always a good idea to take out images with clouds and such manually as APP assumes that you load in data that has decent quality, background light pollution and such it can then correct for, but not clouds for instance.
