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.
2026-10-03- UPDATE FROM MABULA
I am glad to announce that I am finally fully healed, my energy and strength are really back now !
In the past 3 weeks while recovering, I have prioritzed the release of 2.0.0-beta47. So much work has accumulated into this release that it needed to be tested extensively, but also it needed to be available for all of you. Unless a big problem is reported for this release, I expect it will be the final release, finally !, before the official 2.0.0 release.
I browsed the forum for the information I am seeking, but could not find an answer to it, hence my posting. I have started to make wider use of multi-narrowband filters, and have been using the Multi-NB extract Ha+Oiii (and Sii+Oiii) when processing in APP. I am happy with the results but have started wonder what the differences are between the Adaptive Airy Disk algorithm and the algorithm used in the Multi-NB Extract algorithm(s). Having read the in-app instructions/descriptions, I gather that
- For images captured with Multi-NB filters, the Multi-NB Color algorithm is an improvement over AAP’s default Adaptive Airy Disc (AAD) algorithm.
- The AAD algorithm maintains Oiii data quality and sharpness, since the Oiii data has information in both the blue and green channels.
- For the Ha (and I assume Sii) data, the AAD algorithm is not as suitable.
- The Multi-NB Color algorithm treats the Ha (and Sii?) data totally separate from the Oiii data and gives a much better reconstruction of the Ha and Sii signal as compared to the AAD algorithm.
- In the stacked image, the noise in Ha and Sii data will be lower and yield a higher Signal-to-Noise Ratio (SNR).
The only obvious difference, based on the in-app documentation, is that Oiii occupies both the Green and Blue channels, whereas for Ha (and Sii) most of the signal is in a single channel - Red. Without giving away proprietary information, would it be possible to learn, at least at a high level, what the processing differences are? I really like knowing how things work under the hood.
Thanks again for producing such a quality product!
Regards, Martin
Hi Martin.
I am pretty sure (and remember) that APP/Mabula is doing a much more accurate separation of R-G-B into Ha-OIII resp S2-OIII than just
- setting Ha=R, resp. SII=R
- and OIII = G/2 + B/2.
See this link, documenting how PixInsight’s DBXtract is working: https://pixinsight.com/forum/index.php?threads/new-script-dbxtract.23344/
In my words: (Here explained for the Ha-OIII dualband filter)
- Ha is not only in Red, but also a small part of Ha is in B+G
- OIII is a filter- and camera-dependent mix of B+G, not just the average.
In PixInsight’s DBXtract, you can enter in the parameters the camera/sensor, and the filter parameters. Some popular filters are pre-configured.
I guess that Mabula uses the camera, and general parameters for the dualband filters. According to some comments in Cloudy Nights forum (sorry, I don’t find now), then camera signal behaviour ist the important part, and for the filter you can use a general scheme. All better than just „Ha = R“ and „OIII = G/2 + B/2“.
In addition, I remember that Mabula is tailoring the de-mosaicing so that HaO3 (and S2O3) are better/cleaner.
Best regards.
Michael
Michael - Many thanks for your response. I appreciate you steering me towards DBxtract and how it mixes the channels. I have been using it, but will give it some additional scrutiny. And I do agree that R, G, B is more than just R, G, and B.
Given the in-app description of how Oiii is treated vs. Ha, the only difference I could suss out is that the majority of the Red signal is in the Red channel, whilst Oiii does occupy both G and B channels, and that this may be the reason for treating the Red Channel differently than just the Generic AAD algorithm. Perhaps there is a custom "mix" of channels to get the best results, but it would be interesting to learn what APP is doing in this regard while stacking, and are there any impacts downline to processes such as DBxtract.
Regards, Martin
Hi Martin @martinontheroad and Michael @michaelacg,
Let me give you some more background on this.
First of all, the regular Adaptive Airy Disc or AAD demosaic algorithm is only advised for regular RGB data. The algorithm used the green information to both improve on interpolating blue and red. For OIII, the blue construction can obviously still use green pixels, since OIII has signal in both green and blue. But for reconstructing red, when we use a H-alpha/SII filter we obviously do not want to use green pixels. That is the main reason why AAD is not suitable for Multi-NB data. The Multi-NB color/mono algorithms construct green and blue in the same way as AAD, but the red channel is done separately, so not using correlation with the information in the green channel.
Then the relationship between the green and blue pixels for the OIII data, that is actually very important to get the best quality. If you simply do OIII = G/2 + B/2 , then you will not get the best result. The proper relationship can be found with analyzing the green and blue pixels, it will give a certain ratio which you need to use to combine G + B to get OIII. You do not need special parameters like gain or sensor specific values. You can dynamically calculate it, that is what I implemented in APP.
Mabula
Mabula
First of all, I am glad to hear that you are recovering from your illness(es). I feel bad for bothering you with such a relatively minor question during that time.
Thank you for taking the time to answer my question. The approach makes very good sense for such narrow-band data as opposed to broadband imagery. I am definitely filing this away in my “Lessons to be remembered” folder.
Good new on the coming release of Beta-47. APP continues to be my initial stacking and preprocessing software. I crop to remove stacking artefacts and then apply light pollution reduction/background calibration. When I move into Pixinsight, I find that gradient removal algorithms are unnecessary. I find APP corrects them so well that there may only be a change in the 4th decimal place across the image. Well done, sir!
Regards,
Martin
Hi Mabula,
Glad to hear you are feeling better. If the Adaptive Airy Disc algorithm is only advised for RGB data from OSC camera, what algorithm should I be choosing for a monochrome camera with narrowband filters? Or monochrome camera with LRGB filters?
Thanks, Tom
@tfergu01 - I would infer that the AAD algorithm is best suited for broadband data, vice narrowband data that will show strongly in two of the color channels (e.g. Oiii in Green and Blue). I've not shot mono (yet), but my understanding is that one uses broadband filters in the R, G, and B spectrum. There is a less of a need to interpolate the R, G and B since they will bleed over into each other. However, I will defer to Mabula's response. These sorts of questions I find fascinating, as at first blush I don't think to ask as I am too busy learning which buttons to push.
Clear Skies - Martin
Tom (@tfergu01) and Martin (@martinontheroad)
My understanding is that no debayer algorithm is applied to data from a mono camera, regardless of the filter used. It wouldn't make sense, as there is no bayer matrix on a mono camera. Each pixel just records whatever passes the filter. With a mono camera colour doesn't come into it until the rgb combine tool is applied. There is usually a filter tag in the fits header, but no colour information for each pixel.
I believe that means that the selected algorithm is just ignored for mono cameras.
JC
@connor231 - John, You are correct. There is no deBayering with mono data. Its just the pixel gathering light. I'll wait to see what Mabula has to say, as I'll keep (incorrectly) putting an OSC slant on it, since that is my experience.
Martin
Hi John and Martin,
That makes sense. I guess my little brain didn't realize that was a debayering algorithm and therefore with no color information there is nothing to debayer. I just thought I had to choose a way for APP to process the data. Look at that, I learned something new today. Now I can just chill out for the rest of the day!
Thanks, Tom
