• IMPROVED INTERNAL MEMORY CONTROLS / FASTER AND MORE STABLE ON BIG DATASETS

  As reported here : https://www.astropixelprocessor.com/community/main-forum/randomly-stopping-freezing-during-integrations/#post-34236 APP could stall/slow down or even freeze when processing big to very big datasets (500+ frames). The lastest APP releases have many code optimizations making it quite a bit faster, but the memory clean up internally was not able to keep up with all the GigaBytes of data that were processed. The old memory controls internally were fragmentating the memory causing these instability issues now and more quickly as well. Luckily, we are able to prevent this fragmentation completely by using a very different memory configuration internally. Technically, we have switched APP from using java's default G1 garbage collector with many G1 tweaks to using the more advanced Z garbage collector. This proves to be much better for data throughput and stability. Processing big datasets should not slow down APP at all anymore after having done several 100s of  frames in integration.

• FIXED CPU IMAGE VIEWER

  Beta42 introduced a regression bug in the CPU image viewer, so it no longer worked. This is fixed.

• FIXED NARROWBAND EXTRACTION DEMOSAIC ALGORITHMS

  Beta40, 41 and beta42 had several bugs for Multi-Narrowband and also Narrowband processing using OSC / RGB camera's. These are all fixed now. These bugs were regressions from introducting the new resample and drizzle engines in beta40. These new engines are quite a bit faster and now should be bug free as well.

I am doing RGB frames at 120s, dualband frames at 180s, in Bortle 5-6.
Per session some 60-100 frames. In total, I do 10+ hours integration, so mostly >300 frames, up to 1000.

For a single session, I need to discard all frames with satellite trails. (Of course, I also discard frames with clouds, airplanes, guiding problems, and very strong satellite trails). If I leave a single satellite frame in, I see the trail in the stacked result.

Usually, I have 

• very few, only 2-3% of really unusable frames (wind, airplane)
• but 15-20% of frames with satellite trails. So a lot, worthwhile to think, whether/how to keep those.

I am using still 2.0.0 beta39, my parameters are:

• RGB: adaptive airy disk, in 5) no neutralize background, in 6) LNC 1st, 3 iterations, bayer/x-trans drizzle, scale 1, droplet 1. Rest standard
• Dualband: Multi-NB extract Ha+OIII, 5) no neutralize background, 6) LNC off, rest standard.
• I tested (in beta39) a lot with 5) neutralize background and 6) LNC ...
  ... and came to the conclusion that the above settings are best as input to PixInsight's processes to correct the gradient (MARS, GradientCorrection, DBE). If I „smooth“ more in APP, I either loose faint details (e.g. IFN) or get worse gradient correction results.
  (I use APP for stacking only.)

My questions:

• Are there any better settings to eliminate satellite trails, for one session, 60-100 frames ?
• If I have 200+, or 300+ frames: Does it make sense to leave the satellite frames in? Will the trails be „outliner-ed“?
• Is beta42 better in removing satellite trails?

Thank you and best regards.

Michael 

• Upgrade development platform to Oracle JDK 26.0.1

  JDK 26 has several nice improvements for performance of APP! The garbage collector, the system that frees memory after object allocations, will now instantly free the memory of our images once we no longer need them. Previously, the garbage collector needed still to perform analysis before freeing these large parts of memory. With instant release, performance of APP is definitely improved overall. Please see this for technical background from Oracle: https://bugs.openjdk.org/browse/JDK-8048180

  Another free improvement of using JDK 26 is more technical, it relates to how the internal garbage collector works. It is described in JEP 522 : https://openjdk.org/jeps/522. Simply put, APP's performance instantly improves several % is the indication.

• FIXED reported crashes in integration on Windows and macOS

  Several users have reported random crashes / instability on Windows and macOS with beta40/41. By upgrading the development platform to Oracle JDK 26.0.1 these crashes are fixed. APP runs stable now also on heavy workloads where many ! images need to be integrated.

• 5) NORMALIZE upgraded ! More robust and better with bright/HDR objects.

  The normalization engine has been upgraded. The calculations of the sky background (lokation) level and the dispersion (the spread of the pixel values relative to the sky background) have been improved. Previously we calculated the sky background and the dispersion in blocks spread over each image (or overlap area) and not the full image/overlap area was analysed. This was a fast and effective method. But in the new normalization engine, the whole image or overlap area is now analysed and not in blocks. We are using very fast sorting of all the pixels values and we then aggressively clip the distribution on both the positive and negative side to get a very good sky background estimate. We then calculate the dispersion as MAD or BWMV on only the truncated distribution. Testing has shown that these methods are more robust on data with bright/HDR object and strong gradients. OVeral the sky background/lokation and dispersion values will be more robust leading to better image normalization and also better initial background neutralization by the normalization engine and the neutralize-BG option below the histogram. Initial normalization for mosaics with bright objects will be much better as a consequence. Previously we had two modes in the normalization engine: regular and advanced.

  The new engine still has 2 modes, but they work differently and so we have renamed them. The first mode is now called full-image. This mode is most similar to the previous regular mode. The new second mode is called overlap area and this mode is more similar to the old advanced mode. Full-image always analyses each image fully as the name indicates. Overlap area mode will only analyze the overlap area between the image to be analyzed and it's reference frame. If you run a mosaic, and an image does not overlap with the main reference, another frame that does overlap with the image to be analyzed will be used to calculate the overlap area. Simply put, for normal registration where most images overlap almost fully, using any mode will give nearly identical results. if the images have some difference in Field Of View, the overlap area will be more robust because the sky background and dispersion will be based on exactly the same field of view. If however, you run a classic mosaic, like a 5x5 mosaic with only 10% overlap between the images, the full image mode will be best. All is explained as well in new tool tips, the little pop up menus attached to each option. The below screenshot shows the initial normalization of a 3x3 HDR mosaic of M42 with the new normalization engine in Full-image mode. The sky backgrounds already match very well. LNC and MBB only need to do little work to make it a seamless mosaic now.

 The new tooltips are shown in the next screenshots:

• Image Normalizer is further optimized

  The image normalizer is the module that applies normalization parameters to an image. By optimizing this, performance overall is again increased, especially in 2) Calibrate (flat normalization), 5) Normalize and 6) integrate where images are normalized. OSC/RGB data will have a nice performance gain from this.

• FIXED RGB Combine normalization

  As reported here https://www.astropixelprocessor.com/community/main-forum/excessive-auto-stretch-in-rgb-combine/#post-33297 the rgb combine tool could produce very bad and weird looking results. The issue was caused by not properly normalizing the data internally. The issue is solved properly now. 

• FIXED CALIBRATE STAR COLORS & RGB COMBINE TOOLS

  As reported here https://www.astropixelprocessor.com/community/main-forum/strange-calibrate-star-color-behavior/#post-33826  , the Calibrate Star Color tool could exhibit very weird behaviour creating fully red results instead of a nicely calibrated result. The bug was caused by the RGB Combine tool not removing old FITS tags from previously background calibrated files. This issue has been fixed. The problem caused Calibrate Star Colors to think that the image was properly background calibrated, but it was not and needed to be properly background calibrated first before running Calibrate Star Colors. Another related bug was solved as well that would cause the RGB Combine Tool to use wrong background lokations and dispersions to normalize the data.

• FIXED 0)COLOR SETTINGS single NarrowBand demosaic algorithms

  Multi-NB extract Ha, O3 etcetara and the other Narrowband algorithms like Hydrogen-alpha, Nitrogen II etcetara were not working correctly. They would produce a smeared result as reported here: https://www.astropixelprocessor.com/community/appreleases/beta-41-multi-nb-extract-h-a-gives-smeared-result/#post-34238 This issue has been fixed. Algorithms like Multi-NB Ha+O3 that produce multiple stacks at the same time still worked fine, the issue concerns only the algorithms that would produce 1 monochrome narrowband stack from a OSC/RGB image that needs to be demosaiced.

• FIXED ArrayIndexOutOfBoundsException in FindBestRegistrationModel 

  As reported here https://www.astropixelprocessor.com/community/main-forum/arrayindexoutofboundsexception-in-findbestregistrationmodel-while-registering/#post-34227 an ArrayIndexOutOfBoundsException could be thrown when registering in the FindBestRegistrationModel module. The issue will be caused when dynamic distortion correction is enabled. When disabled all works as expected. The issue would manifest if APP tries to calculate distortion correction on data that really does not need it for already perfect registration. The issue is now solved and prevented by simply disabling distortion correction completely in the 2-view registration phase on data that has very little movement in the stars between the images. The user can simply leave distortion correction enabled, internally, APP will disable it for the specific registration task.

• FIXED & IMPROVED CORRECT VIGNETTING, REMOVE LIGHT POLLUTION, CALIBRATE BACKGROUND, CALIBRATE STAR COLORS

  As reported here https://www.astropixelprocessor.com/community/main-forum/star-colour-saving-causes-computer-freeze/#post-34327 if APP is calculating in the Calibrate Star Colors tool and you would push the OK & SAVE button while still calculating, APP would freeze and it would also produce an error on the command line through system out. This bug was present in all 4 tools as indicated in the bullet point for this release note. Another bug was pushing the Cancel button while calculating, it would also produce an error on the command line. Both bugs have been solved. If you push the OK & SAVE button while calculating, the tools will simply wait until the calculation is finished. If you push the cancel button while calculating, the tool will stop properly without showing an error on the command line. During these tools, a little popup window can appear showing progress, we have removed this popup because it no longer serves a purpose and can be quite annoying as well.

• RGB Combine Tool removed popup window

  During the RGB Combine Tool, a liitle annoying popup window would show indicating loading of images. This popup has been removed.

• HSL Selective Color Tool removed popup window

  During the tool, a liitle annoying popup window would show indicating loading of images. This popup has been removed.

• ALL BATCH TOOLS removed popup window

  During all the batch tools, a liitle annoying popup window would show indicating loading of images. This popup has been removed.

• FIXED BATCH CROP TOOL up/down arrow keys offset fields

  When drawing a crop in the batch crop tool, you can move the crop with the up/left/right/down buttons. Next to the buttons, you see the crop offset fields. You can enter a value directly to change it. Or you can use the up/down arrow keys to increase/decrease the offsets. The up/down arrow keys were no longer working. This is now fixed and they work now again as expected.

  10843
• FIXED NullPointerException in RegistrationActionListener: Cannot read the array length because "coor" is null

  We fixed a Null Pointer exception in the registration engine that could manifest in rare cases.

I've been using APP for some time now and really like it. So thanks for developing such a great piece of software.

I have ordered the following filters.

Altair Ha Sii Oiii DualBand ULTRA 6nm Filter COMBO

Exactly how would I process the resultant images in APP so that I would end up with 3 separate images: Ha, OIII and SII?

Regards,

Brian

I’ve been testing APP 2.0 latest release on a new system and wanted to report a consistent issue.

System:

• Windows 11
• i7-11850H (16 threads)
• 64GB RAM
• RTX A4000 laptop GPU

Dataset:

• ~400 light frames
• 16-bit, ~49MB each

Behaviour:

• 2.0.0-beta41 (Oracle JDK 25.0.2)
  → crashes during integration and drizzle (javaw.exe faults)
• 2.0.0-beta38 (GraalVM 24)
  → same dataset completes integration and drizzle successfully

Notes:

• No issues on older laptop (32GB RAM) with earlier 2.0 builds
• Reducing threads did not prevent crashes in beta41
• Beta38 runs stable even with 10 threads

It seems related to the newer Java runtime / memory handling in beta41.

Happy to provide logs if useful.

Thanks for all your work on APP.

kind regards 

Bryan 

P.s. had some help from AI solving this problem and when I asked if I should report my findings back to you it strongly recommended this and composed the above message 😊

Simple uncalibrated Sony a7RV file do not register right. A meridian flip happened inbetween. As can be seen of the reg. error in the screenshot belwo, something is not good. When I tried to display a sub as registered, the below error message occured. Guess I will go back to version 39, where this did not matter

Thank you and best regards.

Michael