June 24 2026 APP 2.0.0-beta46 has been released !
Improved internal memory configuration (lower ! memory usage), fixed beta45 startup issue, fixed Set Save Directory & 2-panel mosaics.
May 27 2026 APP 2.0.0-beta45 has been released !
Fully Multi-Threaded LNC, many improvements for the registration engine, platform upgrade, and further tuning of internal memory consumption and memory release back to OS.
Apr 14 2026: Google Pay, Apple Pay & WeChat Pay added as payment options
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.
Is there a plan to also release APP as a library in the form of a JAR file?Â
If that was the case, one could make wonderful bindings on top of your great work! I for one would write a clojure (a jvm side lisp) wrapper, allowing this to run live through a repl where I could script away common tasks or even save entire workflows for each photo as clojure scripts so I could reproduce any photo at any time on any machine precisely as I had done it originally. This could give us (the astrophotography noobs) much deeper insights as we learn this fine art and could see what we did and how it improved.
Thanks for a wonderful program!
Thanks for the compliment! As I program myself as well I actually had a little conversation about something similar. But for now it's not something to be made possible, it would complicate the program fast at a stage where it's still fully in development. So great idea, but not going to happen at the moment.
Thank you for replying!
Yes, I can see that the program is in full development swing. I am not expecting this to happen at the moment, just thought of instilling this ideas in the designers head. As a developer myself, I know that having this concept in mind adjusts the architecture and design of the application such that later it will be easier to export the functionalities as APIs.Â
I have worked a lot on very memory intensive projects on the JVM and I have lots of ideas for you to improve performance, reduce GC jitter, etc. For example I am not sure if you are currently using DirectByteBuffers, which allocates memory off heap (think malloc, thus reducing GC stress). This approach will also allows for future interfacing with jni code which could then take advantages of SIMD instructions ( https://www.quora.com/What-is-SIMD ) for very fast computations (think GPU on top of the CPU). Unfortunately the JVM as it is currently lacks proper automatic vectorization which this kind of processing could easily use.
If you would like to have some technical session, I would be thrilled to help out. Astrophotography, although a hobby at this point in my life, is a big passion of mine as well as programming, so I would love to contribute 🙂
Yep, same! 🙂 Although not Java and still starting out in the scene. I'll tag Mabula so he can chime in. @mabula-admin
