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,
I observed a strange effect which might be a minor bug or a non-issue:
Running a full stacking process, the RAM usage of ARR ramps up while Analize Stars process, lowering below 16GB for APP afterwards. However, the OS RAM usage display ramps up during Normalization until it reaches the ceiling (64GB on my computer), while APP usage remains below 16GB. Strangely, the CLEANER PRO APP is showing only half the memory is used in total (around 20-30 GB). See below screenshot, in the menu bar to the right.
 So which RAM usage exactly is indicated by APP? - Â
My suspicion is, SWAP memory on the "Flash SSD" is being used by APP which seems to be a black hole for APP's counter - only stored information is counted but not if any of the SWAP is reliefed again.
Having said that, even while operating in the "red zone" through half of Normalization and all Integration stages, APP behaves normal, without slowing down up  to the very end of the process. It' just a bit loosing control on what's going on actually.
I am running MacOs 12.4 on a Mac Studio with M1 Max & 64 GB RAM
APP now uses up to 98% of the available memory. I guess it determined here it would need a lot during the process, let me ask Mabula for specifics.
Hi Jochen,
The memory that APP is claiming is the 10082 MBs number out of a possible 57096 MBs. The RED numbers for your OS indicate that the OS as a whole is consuming a lot possibly to other tasks/applications on your operating system?
What is macOS reporting for memory usage for APP at such a moment with macOS system monitor ?
Mabula
Hi Mabula,
the strange thing is, APP was the only major Applicatio running, additionally I had just minor surveilance Apps like  TG Pro (fan control), Cleaner Pro running idle. These, without APP do not use  RAM extensively. Even when APP was indicating 98% for APP and 100% for OS, the total amount used seemed to be just 31% as indicated by Cleaner Pro - which might translate into the RAM amount used by APP actually. Also, I recorded processing speeds and I couldn't see any hint of a slowdown which would be expected in RAM overload phases. I may provide You a high-level protocol of yesterday's stacking process, including temperatures, fan speeds and time stamps (I was just nerdy-curious 😉
Jochen
Hi Mabula,
here is a snapshot while Normaliztion:
APP RAM is indicating 22 GB while Activity Monitor is pretty much in line with 21GB for APP. However, OS read is already ramped up to some 64 GB in APP and I think I know why: in Activity Monitor, I could see a high amount of Cache used (34 GB) and a lot of Compressed Memory 45 GB, but 0 Swap. You can also see the CPU cores loaded nicely in the graph, with the GPU cores idle around 10% Avg. or 25% burst load.
Hope this helps,
Jochen
Â
Â
Hi Jochen @jochen-scharmann,
So nothing is odd then. APP is reporting the same memory consumption as is macOS.
What macOS is doing besides that is on the operating system level and completely out of our control of course. If it is data for cache that consumes the memory on OS level, I would not be concerned, because it would be released if another application really needs it 😉
Mabula
Thanks Mabula, I agree...
what puzzled me is that I never saw the "OS" RAM usage ramping up to 98% on my old Intel i7 Mac...
I am not sure if it helps to count in the cache size, as cache usage is just temporarily and would be reliefed as You said. Ideally I would expect APP to display just "real" RAM usage in total. If you watch red letters@100% it's hard to tell yourself it's nothing to worry about 😉
Thanks again for Your great support!
Jochen
TÂ
