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.
Hi,
I have two mono cams from different FOV and filters and working through a process to make best of the data from them.
The filters are Antlia 3.5nm SHO from a Sharpstar 76, and Chroma 3nm SHO from a Sharpstar 107. A distint difference in quality and FOV, but useful nonetheless as I use the data for all my SHO images.
To start with I was doing a comparison of a Hubble 3 formula of each set of images/filters, registered to the same FOV and object, so I can use them both for a fair comparison.
The comparison is below straight after integration and combine tool:
Antlia 3.5nm SHO Hubble 3 from 76
Chroma 3nm SHO Hubble 3 from 107
Â
All subs (each SHO) are 10 mins long x 5 and basic calibration, integration per filter and session and combined individually.
Â
So far so good. But so I can do a fair comparison I decided to use APP to crop _before_ I combine in RGB tool.
I get different results. Can you explain why? Is it the autostretch because the extra black/non-DSO parts are not being included in the stretch?
Â
Antlia 3.5nm SHO Hubble 3 from 76 Cropped then Combined
Chroma 3nm SHO Hubble 3 from 107 Cropped then Combined
Â
From the first combine, uncropped, the comparison showsa bigger difference in colours, withe the Chroma being the closest to where I want to be before post-processing.
However from the cropping of the image to match each other's FOV before I combine, the data is slightly more subtle (still a difference, but they are closer matched).
What is the suggestion here on next steps -- do I use the cropped or uncropped data, and does it matter at this point if I save as a TIFF to post-process in say Adobe and do further colour balancing?
Hi @itarchitectkev,
Thank you for sharing this. I think the difference will be mostly from the normalization in the RGB Combine tool. Did you play with the normalization settings or not? The RGB Combine Tool by default will again normalize the input data, if you disable it, I think the results for cropped and uncropped will be the same apart from a slight stretch difference. So that means colors would be the same.
If you crop the data, then normalization parameters will be different leading to different outcomes.
There is no suggestion since both cropped and uncropped data will be the same in the linear base, it just depends on what formula preset you decide on and then tweak the formula. No formula preset will be ideal, they are just there as starting points. So need to transfer to Adobe if you would ask me, because then you will be forced to transfer stretched data, which is a big loss in flexibility in processing in my experience.
Mabula
