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.
I'm currently working on a mosaic of the Carina nebula. Four panels - mono camera - four filters (HaRGB).
This means I will have 16 integrations to combine. It seems to me there are two ways to go:
Option 1 - Mosaic the panels for each filter. Then do RGB combine, light pollution reduction, etc on the "mosaiced" images.
Option 2 - Start with RGB combine, LPR, etc for each panel and combine the mosaic as the last step in APP.
I think each option has some advantages. I have been using Option 1 for testing while I am still getting data and it seems to work OK.
My question is - can a strong case be made for one of these options over the other ? Or does it just come down to minor differences/personal preference ?
I don't know enough about the interaction between normalisation and mosaic processing, but I would not be surprised if Option 2 was technically superior. I would apreciate any comments.
thanks
JC
Option 2 is better I think (there are more ways to Rome for sure), but I would also try option 3. Which is creating the panels first, so panel 1 fully integrated as HaRGB. This panel doesn't have to be corrected yet as creating a mosaic will change things anyway. Load these panels as lights and then create the mosaic. This mosaic can then be fully corrected.
ps. I guess your option 2 is basically this, I just removed the correction steps. 🙂
Vincent
Thanks for your comment. I hadn't even considered your option 3, but I suspect you may be on the right track.
I was hoping for a technically based/justified response - maybe even some words of wisdom from the man himself, although I wouldn't want to distract him from getting 2.0.0 stable ready for release (grin).
regards
JC
The man himself is very busy, but I can ask if you really need that. 🙂 One of the things to use my option is that, while you can correct the panels first as well, the calculation of creating the mosaic changes the background again. This has to do with the overall statistics in that algorithm. Which makes that it's better to correct after creating the mosaic.
Besides that combining entire mosaics and registering those with each other is an ok option as well, but less manageable when the mosaic gets bigger. The algorithm is optimized for creating the mosaic from the panels.
Thanks Vincent
I think you have given me enough to think about and move forward - probably don't need to bother the man.
regards
JC
No worries if you do need more detailed information. If anything is unclear in your further testing, just give us a shout.
Vincent
Here is my finished mosaic, probably with too much colour saturation as I can't help myself.
I tried processing this the way you suggested in option 3, but it didn't work well. I ended up with something with different colour issues in different parts of the image. Perhaps I stuffed something up, but anyway it was worth a try.
I ended up going back to option 1. I started by first creating a mosaic for each filter, then LPR for each filter and then processed more or less normally from that point onward. The star colour calibration step didn't work as normal - I suspect the starfield was so dense that APP mistook stars for nebulosity, but I'm just guessing about that. One thing that supports that guess is that I tried a star reduction and it only changed a tiny fraction of the stars in the image. I ended up doing star reduction outside of APP.
Still, I'm fairly happy with the end result.
Carina Nebula (downsampled) 2x2 mosaic.
The different colors in the end result can be normal, due to variations in calibration between the panels. But that usually is solved with some careful light pollution correction. In any case, you found another workflow that seems to have worked nicely. If you want I can always have a go as well. 😉
Thanks Vincent - I think I'm good for now. I did try to fix the local colour issues with LPR, but it was pretty difficult with the way the nebula sat in each panel.
Anyway - thanks for your help.
JC
