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.
Workflow challenges in multi-session, NB mosaic: gradients, banding
I'm working on a multi-session, narrow band 2x3 mosaic of the Heart Nebula. I've accumulated 3 nights worth data, calibrating and save each nights good subs for later processing by panel through a typical NB workflow: integrate each panel's channels, RGB combine, apply LPC, crop, and then integrate the 6 panels into a mosaic.
There are two main issues I'm wrestling with:
I'm finding difficult to consistently and effectively apply LPC and normalization across all the panels, especially given the nebulosity
When integrating the panels, the resulting mosaic has visible banding and uneven background normalization.
I'll confess that, even on simple 1 panel nebula images, I find gradient correction challenging so probably making rookie mistakes but am wondering if there is a better workflow to follow (e.g. assemble RGB panels and then apply LPC, ...) ?
Here's a OneDrive link to 2 full size and downsized mosaic samples: the only difference are the Integration LNC settings, 1x1 and 6x8. Difference is slight but the 6x8 is better.
I have spoken with @Mabula-admin about LNC a few times in the past, and this is something that is planned to be worked on (Improving LNC that is). I have done a lot with Mosaics, and I sometimes find that a particular LNC setting works well on some filters, but different LNC settings work better with others, in my case my Ha requires one setting whilst my OIII and SIII require different.
Are you able to upload the individual panels / channels as well? I can then take a look.
Usually either 4-3 or 7-3 works best for me on my images (When I need to use it)
Thanks Simon. individual filter integrations (HA,O3,S2 for all 6 panels) are uploading now to the same OneDrive folder; will probably take another 20 min to fully sync. Appreciate any insights
So, to apply different LNC by filter, are you creating 3 mosaics 1/channel, applying the LNC by channel and then doing the RGB combine?
@snapthot I would typically run the Mosaic creation with LNC 4-3 and then repeat the process with LNC 7-3 for all three filters. I also run a No LNC correction as well, as I find sometimes that Ha doesn't work well with it, but it benefits both SII and OIII.
Once I have done that, I look at all the Mosaics created, usually the No-LNC for Ha gets kept, and then I look at the OIII and SII mosaics and decide which ones are best to keep, discarding the rest, so I end up with three files.
I'll have a play with your data and see what comes out of the wash.
I am going to be honest here on my first inspection and tell you that the issue is mainly down to the light frames, if you look at this frame for example, there is a very dark circle in the middle of the Ha image
The same goes for this frame:
Other frames there is also a dark prominance.
So I have to ask, why is there such a dark prominance in the middle of the images? Were flat frames successfully applied, or was there optical issues like dew causing the darkness in the middle of the frames. Are there some individual problematic frames causing the data to look like this?
I am going to do some other testing on the data, to see what comes out. Just wanted to set the expectation that you might be expecting LNC to overcome a situation that might make things worse.
@stastro Thanks Simon. Very interesting, almost like the lights are over corrected. The flats are generated at our club observatory using an Flipflat. Will go back and review the calibraton frames and see if that’s where the problem starts.
@stastro Simon, i redid everything from the original subs, including creating the calibration masters and creating the mosaic. Similar results to yours but something did occur to me.
The bulk of the subs were captured on 25 Jan with an 88% moon and a meridian flip roughly half way through. I’m wondering whether the dark in the middle is actually the result of the moon gradients on the upper left or lower right of each sub. Each panel was captured in its entirety before moving to the next panel. The lower panels have proportionally more subs captured on subsequent moonless nights and the gradients are not as prominent in the bottom of the mosaic.
@snapthot It could well be due to excessive gradient.
As a test, you can try stacking the frames and during the stacking, use the LNC for each stack rather than using it on the overall Mosaic.
Try stacking each frame with LNC 4-3, then 4-7, then 6-3, and see the difference in the frames.....or.....What I am going to do is use a Gradient Correction Tool on each of the panels, and then perform a Mosaic on them....let me see how that goes
I basically loaded up each frame and created an RGB version of each panel. Then I applied a Gradient Correction against each frame and cropped the black edges from the images.
Once I had them, I loaded them back up in APP and performed a Mosaic with LNC 4/7 and after performing a Magenta Cast removal, this is what it looks like:
So it is possible to recover the data even though they are badly affected by varying gradients as well as some flat artifact:
I am going to be honest here on my first inspection and tell you that the issue is mainly down to the light frames, if you look at this frame for example, there is a very dark circle in the middle of the Ha image
The same goes for this frame:
Other frames there is also a dark prominance.
So I have to ask, why is there such a dark prominance in the middle of the images? Were flat frames successfully applied, or was there optical issues like dew causing the darkness in the middle of the frames. Are there some individual problematic frames causing the data to look like this?
I am going to do some other testing on the data, to see what comes out. Just wanted to set the expectation that you might be expecting LNC to overcome a situation that might make things worse.
To me this looks very likely an over correction of flats actually, solving that will quickly solve all issues here I would think.
An overcorrection of flats will be caused by using incompatible bias/darkflats/darks for lights and flats in terms of the sensor offset used. George, can you double check the sensor offset that was used on all the data. There is likely a difference somewhere on the offset used when capturing your data.
