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.
I have a very odd, non standard, set up. I do a bit of deep sky imaging with my Orion XT12G Alt/Az Dob. Actually get pretty good results but there is one problem I have and it causes APP to occasionally explode in disk, memory usage, and integration time.
My telescope has field rotation, and it can slowly drift a bit off target occasionally before it reslews back onto target. APP does a good job of stacking all these miss registered and rotated frames and I just crop the data afterwards. However it creates a gigantic integration frame which causes APP to explode in resource and time usage.
Also because my tracking is mediocre I take short subs, like 8 to 12 seconds, so I can end up with a couple of thousand lights. That coupled with the giant integration frame from field rotation and small positioning drifts creates crazy resource usage.
I’m looking for strategies to deal with this. Suggestions are appreciated.
I wish I could select a master frame and say crop to this master frame when integrating, ignore any other data outside of this when you’re integrating and don’t turn a 24 megapixel master frame into a 70 megapixel super integration mosaic.
I expect this would cut down the resources required and the amount of memory required to do a stacking. Because right now I have situations where it requires 3-4 TB of disk working space to integrate and takes 8-12 hours on an 8 core AMD 5900 CPU with 16 gigs RAM and a fast SSD.
it sometimes crashes also.
Where is a mitigate this today are:
1) capture in bin2 for these larger integrations
2) presort the frames by deleting ones that I won’t want (poor star FWHM)
3) integrate with a scale <1
these are helpful but some lower the resolution of the final result when I really just want the frame to be cropped.
Yes, 1000's of frames is a challenge. What I would do is to process those in batches. Integrate, say, 300-400 frames at a time, fully calibrated and integrate them. Do this until you have a number of integrations. These integrations can be loaded in again as lights, without calibration data and then integrated again.
Great idea! I forgot I could integrate previous integrations. What is the particular file for the previous integration I should use? Should I save an unstretched TIFF or is it one of the auto saved files?
You mean what you then pick as a reference frame? Maybe you can add the same file to each of the integrations and reference that one? Never tried that myself though. 🙂
@vincent-mod actually, I mean as the new lights, I expect it’s just the unstretched .FITs file APP spits out after stacking.
Oh, right, yes just the integrated result that APP saves, which is a linear (unstretched) .fit file.
