Apr 9 2026 APP 2.0.0-beta40 has been released !
It has a major performance boost of 30-50% over 2.0.0-beta39 from calibration to integration, for mosaics even faster! 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. Improved Outlier Rejection with LN 2.0 rejection. macOS CMD+A works now in file chooser ! And more, all will be added to the release notes in the coming hours...
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.
Have been using APP quite a bit since picking up this hobby and got a license when my trial period ended. One thing I have noticed with it in the last few days is that when using the RGB Combine tool, enabling the Saturation checkbox can often destroy colour gradients where a transition between colours should be occuring - it ends up becoming a very harsh transition between two colours rather than a gradual one. The attachments illustrate my point - same integration, one screenshot taken without Saturation enabled and the other with it enabled. I have been using the tool to try and re-create the SHO palette with OSC Ha and Oiii data.
You can see in the highlighted areas with saturation applied, very sharp colour transitions that are frankly quite ugly, and in the image with no saturation, a much more gradual transition, albeit with significantly less colour. These are 200% crops to clearly show it. Regardless of saturation and Sat.TH slider settings, this seems to occur (short of reducing them enough that there is no saturation visible anyway.)
Any tips for avoiding this? In this case it's working with OSC data, using the Extract Ha and Extract OIII algorithms, ASI533MC Pro, Optolong L-Enhance. This is NGC6188 but I have noticed it on other objects as well.
Cheers
Thanks for sharing. Mmm, this may be something related to having enough data or not for those sections. If the areas are more towards background signal, you may introduce more noise and other artefacts that might make it look like a harsh transition. What happens exactly when you protect the background a bit more by moving the Sat. TH. slider up a bit, it doesn’t make this fade a bit more? And do you have more data for this region from past sessions maybe, might be interesting to know if that helps.
Thanks for sharing. Mmm, this may be something related to having enough data or not for those sections. If the areas are more towards background signal, you may introduce more noise and other artefacts that might make it look like a harsh transition. What happens exactly when you protect the background a bit more by moving the Sat. TH. slider up a bit, it doesn’t make this fade a bit more? And do you have more data for this region from past sessions maybe, might be interesting to know if that helps.
Thanks for the reply. It may be lack of data as you say, unfortunately I have no previous data of this target to add in and test that theory. That said, this was five hours of data under Bortle 3 skies, so it isn't an insignificant amount to begin with.
Regarding the Sat.TH slider, what I had found is that, at least with this particular object, adjusting it up ends up "protecting" a lot of the rest of the object from the saturation changes as well, such that if I have it high enough that the problem is not observable any more, the area of the object has become so desaturated that it's basically the same as unchecking the Sat box. I will have more of a play around with it though and see if I can find a happy median.
I have observed the same issue on another (much brighter) object, indeed in a very bright part of the object where SNR should be highest, although that imaging session was only two hours so again could not be certain that lack of data isn't the cause.
The amount of time per object will be depending on the type and strength of signal, so some parts of the object or even the entire object, may need a lot of time. Which sometimes means 10+ hours per channel. So in your case I think it's more of a combination of a bit too much stretch for the amount of signal there, together with saturation that makes that more visible. You could try to play with the threshold a bit as well as the stretch.
