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 everyone,
I’m currently working on a rather ambitious astrophotography project and would really appreciate some advice from experienced Astro Pixel Processor users and the developers.
The project
I captured a large 21-panel (7 × 3) mosaic of the Rho Ophiuchi region from Isabis, Namibia, under exceptional Bortle 1 skies.
The dataset consists of approximately 105 hours of total integration time, with around 5 hours per panel and 25% overlap between adjacent panels.
My imaging setup:
- Telescope: Askar SQA55
- Camera: ToupTek 24AC (full-frame OSC)
- Mosaic: 7 × 3 panels
- Overlap: approximately 25%
- Total integration: approximately 105 hours
- Location: Isabis, Namibia (Bortle 1)
- Processing: Astro Pixel Processor
- Computer: MacBook Pro M3 Max, 36 GB RAM
My processing workflow so far
I calibrated, registered and integrated each of the 21 panels individually in APP.
Afterwards, I loaded the 21 integrated panels into APP to create the final mosaic.
I’ve experimented extensively with different mosaic integration and normalization settings, including:
- Multi-Band Blending (MBB), including 25%
- Local Normalization Correction (LNC), including second-degree LNC with 5 iterations
- Different normalization approaches
- Different reference panels, including a central panel
- Full Image normalization
- Background neutralization and gradient correction
- Different mosaic integration settings
I’ve also been experimenting with Drizzle during the individual panel integrations. Due to APP’s practical image-size and memory limitations, I cannot currently process the entire mosaic at its maximum potential resolution.
The problem
Despite numerous attempts, I’m still struggling with visible transitions between the individual panels.
The attached image illustrates the problem.
There are noticeable horizontal and vertical structures along the panel boundaries, often appearing as yellowish lines or areas with different background brightness and color.
Interestingly, some of the overlapping regions appear to have a more uniform or cleaner background than the central areas of the individual panels.
This makes me wonder whether the normalization and gradient correction are treating the overlap regions differently from the rest of each panel.
Increasing the strength of LNC and other corrections can improve the visible transitions, but unfortunately it also seems to suppress faint dust and nebulosity.
And that is exactly what I want to avoid.
The Rho Ophiuchi region contains extremely faint and complex dust structures, and with 105 hours of exposure under Bortle 1 skies, preserving those structures is particularly important to me.
I’ve successfully processed smaller mosaics, including 4 × 4 panels, without encountering these problems to the same extent. The difficulties seem to become much more pronounced with this larger 21-panel project.
My questions
- What would be the recommended APP workflow for a 21-panel mosaic with significant faint dust structures and 25% overlap?
- Would you recommend applying gradient correction individually to all 21 integrated panels before creating the mosaic, for example using APP, GraXpert or PixInsight DBE?
- Could normalization based primarily on overlapping regions explain why those regions sometimes look better than the central areas of the panels?
- What combination of LNC, MBB and normalization settings would best preserve faint nebulosity while eliminating visible panel boundaries?
- Could Drizzle integration followed by downsampling or resampling contribute to these artifacts, or is this most likely an independent normalization/gradient issue?
- Is there a recommended strategy for processing such a large mosaic at full resolution, potentially by dividing the mosaic into smaller sections before the final integration?
My goal
I want to achieve a seamless mosaic with a consistent background, natural colors and, most importantly, without sacrificing the extremely faint dust structures captured during those 105 hours.
I’m more than willing to reprocess all 21 panels if necessary, but before investing another significant amount of processing time, I would really appreciate some guidance on the most effective workflow.
I’ve attached an image showing the current result and the visible transitions between the panels.
Any suggestions, recommended APP settings or insights from users who have successfully processed similarly large mosaics would be greatly appreciated.
Thank you very much for your help!
Best Joerg
Joerg (@einneuer)
I'm not really qualified to advise on a project of this scale, but I will say that when I experienced a similar issue with a smaller mosaic I got a good result by applying APP's light pollution reduction tool to the individual panels prior to mosaic registration.
My suggestion would be to pick the four panels with the worst transitions, do a careful LPR on each, and test if the issue goes away.
I would also add in response to your question 6 that Mabula has said that building up a mosaic using smaller mosaics (ie dividing a big mosaic into chunks) is not recommended.
good luck
JC


