Mar 28 2026 APP 2.0.0-beta40 will be released in 7 days.
It did take a long time to have the work finished on this and it will have a major performance boost of 30-50% over 2.0.0-beta39 from calibration to integration. We extensively optimized many critical parts of APP. All has been tested to guarantee correct optimizations. Drizzle and image resampling is much faster for instance, those modules have been completely rewritten. Much less memory usage. LNC 2.0 will be released which works much better and faster than LNC in it's current state. And more, all will be added to the release notes in the coming weeks...
Update on the 2.0.0 release & the full manual
We are getting close to the 2.0.0 stable release and the full manual. The manual will soon become available on the website and also in PDF format. Both versions will be identical and once released, will start to follow the APP release cycle and thus will stay up-to-date to the latest APP version.
Once 2.0.0 is released, the price for APP will increase. Owner's license holders will not need to pay an upgrade fee to use 2.0.0, neither do Renter's license holders.
I have used APP for over four years with great results. In recent months I have had odd results on three separate occasions when stacking added frames. It seems to occur when adding frames from subsequent evenings to already open integration results (i.e. APP was left open and additional frames were added the next day). I am using 2.0.0 Beta 29, Windows 11 Home, Ryzen 9 processor 12 threads, 64 Gb RAM. By closing the APP program and restarting the computer it may then process the frames when loaded from scratch, but last night I had to completely shut down then turn back on and reload the 254 5 minute frames among four sessions and finally got the expected result. I did save the Metadata file if that helps.
Data was from both my RASA 8 /ASI071 MC Pro and FF65/ 2600 MC Duo. Calibration was set to auto, Quadrilaterals, scale 7-15 4th degree LNC, 4 iterations, MBB 15%, Flip descriptors and dynamic distortion enabled, same camera unchecked. Any thoughts on why I got this artifact? Jpeg of better third time result also attached . Thanks much!
https://www.astrobin.com/users/JohnQuinn/ Â
Â
Hi @john-quinn,
That instable result will be caused, by a mathematical problem in the way that we calculate a mosaic using optical distortion correction. If you add frames to an already created mosaic and do enable dynamic distortion correction, I think that the distortion correction becomes unstable on the already created mosaic data somehow. The optical distortion correction assumes that each "light" that you load into APP is a light from the optical setup and represents the optical aberrations of your setup. A mosaic that was already created will not fit into that assumption. That will also be the reason that your result is as expected when you do load all mosaic panels separately and perform the mosaic registration on all those panels together.
I know this sounds very technical. The issue is in our way of calculating this at the moment. I have on our todo list to improve these routines for sure and to build in stablisators for this issue as well.
Hope that clarifies what happened in this case?
So if you encounter it again, please realize that you will always get the best and most robust results if you first create mosaic panels by stacking the lights per panel. Finally, only perform a mosaic registration on mosaic panels. Do not try a mosaic registration on new mosaic panels mixed with an already created mosaic that is much larger than then individual panels. That last path is much more unstable for sure.
Mabula
Thanks for the prompt reply, Mabula! I did use normal registration, not mosaic. I did get data on IC443, 444 and nearby Sh2-249 and set star number to 5000. This did result in the final successful image. I have also had great results with APP's mosaic function!
Â
