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 eagerly downloaded the new version today and went right into some stacking tests. I am running and 8 core i7 processor with 16 GB of ram - 14 of which is allocated to APP. The image data is being processed on a new 500gb Samsung SSD.
There does not seem to be any improvement in star analysis, registration, normalization, or integration.
I did not do a clean install, could there be a conflict causing this?
I like the new calibration options and am going to make a fresh set of masters to take advantage of the upgrades there. The stacks that have completed do seem to have better color and registration, but I need that speed!
Thanks,
Eric
Hi Eric,
As indicated in my topic on the particular integration improvements, the improvements were made in the integration engine, so that means that modules like star analysis, registration and normalisation aren't affected by this. Those modules don't do integration.
And from the testing that I did, the most gains in integration are achieved when integration is done on a conventional harddisk.
If you integrate on a SSD, then integration speed should already be very good due to the much lower latency of a SSD drive versus a conventional drive with moving parts.
If you feel that integration is still slow, then some particular setting might be the issue.
Can you share which settings you are using in 6) Integrate ?
Kind regards,
Mabula
I must have misunderstood on the speed ups. Integration is still not noticeably faster. But these are the settings I use and have been mostly from the beginning after going through the tutorials.
weights - quality
integrate - average
filter - windsor sigma clip
Everything else set as stock.
I'll manage. Thank you for all the work sir!
Eric
Hi Eric,
Okay, for my reference, to be sure integration speed is like it should, can you time an integration? (or post the output of the console, it has time marks)
Process the lights up until and including normalisation.
Then start the timer and start the integration in 6).
I would be interested to know
- how many frames you're integrating
- how many pixels is the field of view of the integration (can be found in the console output when the integration starts)
- how many channels? color or mono
I assume it's not taking hours and hours on your SSD with several 100s of frames, but do let me know if it does.
Your timer result would be useful to me to scale the result to my test results, so then I would have a better indication if APP behaves like it should on your machine or not.
I did test a lot, on different Operating Systems as well, but all information on this is helpfull 😉
Kind regards,
Mabula
Mabula
As a follow up to this I have some more information for you. I followed your above directions. Completed all tasks but integration then timed it. Details as follows:
150 fits frames, 4656x3522 dimensions
Master dark and BPM
Weights set to 'quality' and 'average' with Windsor Sigma rejection
This took 10:22 to complete. Is this in line with your testing? Considering the amount of data being integrated I shouldn't be complaining, but just curious if this is correct from your perspective.
I also posted a separate topic on not being able to view any images in the previewer anymore - raw subs, darks, integrated, nothing. Very odd, and difficult to manage results now.
Thanks,
Eric
Hi Eric,
Thank you for testing this 😉
- Winsor rejection is a bit slower than sigma clipping, I tested using sigma clipping mainly.
- I used 16MegaPixel RGB data, did you use mono or RGB, RGB is three times more data to process...
If you start integration, the progress indicator until 30 is loading all the frames into the stack. Then all after 30 is the actual integration.
My test results showed this:
16MP RGB data, 100 frames with sigma clipping 2x kappa 3
Conventional (non-SSD) drive:
13 minutes for loading all images
integration 7 minutes
Total = 20 minutes.
With LNC 1 iteration, 9 more minutes.
On SSD drive:
13 minutes for loading all images
integration 6 minutes
Total = 19 minutes.
With LNC 1 iteration, 6 more minutes.
So based on your results, I would assume you used 16megapixel monochrome images?
If so, to scale my results, they need to be divided by three ( RGB 3 channels > mono 1 channel) and we need to adjust for you integrating 150 images as compared to me doing 100, so multiply with 1.5.
Conventional
(20 minutes / 3 ) * 1,5 = 10 minutes
SSD drive, also roughly 10 minutes.
So yes I think it's prefectly in line with my testing then 😉 and pretty fast considering you used winsor clipping which takes a bit more time. If you used 16MP RGB files, I would be amazed about the speed...
I would assume that an integration time of 10 minutes for 150 frames is very reasonable, right?
(I will work on further improvments off course ! )
Mabula
