2026-10-09 APP 2.0.0-beta48 has been released !
This is mainly a bug fix release for the reported bugs in beta47. In addition it has a significant User Interface performance improvement noticable when you need to process 1000s of images in APP.
2026-10-03 APP 2.0.0-beta47 has been released !
This is a very big release... many code optimizations/rewrites, many parts of APP are much faster and more precise, especially star analysis and registration are much faster ! Big mosaics will go much faster 🙂
And we introduce a new preview filter, which includes the new Adaptive Deep Sky Stretch and a General Levels Stretch, this has been long over due. The old preview filter (the panel on the right side to stretch and preview your data) has not been updated for a couple of years and it is a critical part of any APP session.
Adaptive Deep Sky Stretch or ADSS is a much more intuitive stretch algorithm. It is also color preserving (which is a great new addition in itself ! ) which means that the highlights are no longer bleached, color is maintained from the linear data while stretching. You can simply stretch your data using the sky background level and signal width sliders which work much easier and more intuitive. You no longer need to fiddle with the old complicated sliders with zoom buttons. All the zoom buttons for the sliders are made redundant. And you can enter slider values in the slider value fields yourself. I will make a youtube video in the coming days to explain and fully introduce ADSS. Once the video is ready, it will be highlighted on the forum.
RGB Combine upgrade !. The RGB Combine Tool has been rewritten mostly. The tool is faster and easier to use and most importantly, the Luminance slider to inject a luminance channel or channels into the RGB composite is now working correctly. It no longer bleaches the RGB colors. Combined with the new ADSS preview, you will get much better and easier great composites with great color! I will also explain this in a new youtube video.
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.
