IMHO, the new naming of Normalize modes is a bit confusing/counterintuitive...

"overlap area" - would be good for mosaics since the panels usually overlap 10-20%
"full image" - would be good for regular integrations where panels fully overlap

But, regardless, currently the default mode is "full image" which is supposed to be for mosaics.
Please change the default to "overlap area".

Or I am wrong?

Thanks!

Max

Seem's running but nothing happens.

The JDK process is running.

Rolling back to beta44 works well.

Do you know the issue?

Best Regards

Just a 2 panel mosaic: unable to register, as shown in screenshot.

I tried all different settings in 3-Register without success.

I show you all my settings.

Thanks

Just spreading some love to APP!  Héctor

I have just tested beta 45 on Linux Mint with a simple integration. 100 aps-c frames, colour camera.

Everything seemed to work fine. Performance was good and memory management seems to be significantly improved.

However, the issue I raised in this post (https://www.astropixelprocessor.com/community/main-forum/beta-44-memory-issues/#post-34588) still exists to some extent.

OS ram went to about 80gb. Significantly better than the 90gb used by the previous version, but still a concern. I would speculate that this may be causing performance issues for those with 64gb or less of ram (or perhaps this is a Linux only issue? I don't know).

Still - all in all its a good result. You must be getting real close to 2.0.0 now 😊 .

JC

This release has many fixes, improvements and new optimizations especially for the new registration engine that was introduced in 2.0.0-beta39. And fully multi-threaded Local Normalization Correction.

• UPGRADED development platform to OpenJDK 26.0.1

  We moved from Oracle to OpenJDK because of the next release note, to further improve the internal memory configuration and cleanup. 2.0.0-beta45 is using the Shenandoah adaptive garbage collector (developed mainly by the open source community and Red Hat) which is again an improvement over the new configuration in beta43 and beta44 that were using the Z garbage collector.

• IMPROVED memory configuration

  We have further tuned the internal memory configuration to prevent Out Of Memory and Memory fragmentation on big datasets as reported here: https://www.astropixelprocessor.com/community/main-forum/encountered-error-in-module-createqualityregistrationdescriptorstask/#post-34515 We are now using adaptive Shenandoah garbage collection in the java runtime. Memory should be released back to the Operating System more quickly than with beta43 and beta44 while maintaining processing speed.

• IMPROVED ALGEBRA, MATRIX INVERSION - performance improvement !

  We used to rely on a third party algebra library  (EJML) to do matrix inversion. The library could do it quite fast but only single threaded. This was the last remaining issue for getting fully multi-threaded Local Normalization Correction calculations for example. We have now implemented our own very fast single thread matrix inverter which out runs the EJML matrix inversion on small matrices with a factor of almost 10. And ! we have also implemented a multi-threaded matrix inversion which really helps to improve performance in both the registration engine and in speeding up Local Normalization Correction on big datasets.

• IMPROVED LOCAL NORMALIZATION CORRECTION, now 100% multi-threaded.

  As a result of our new multi-threaded matrix inversion that we implemented. LNC is now fully multi-threaded and so this is a nice performance gain for anyone using LNC.

• IMPROVED 4)REGISTER, 2-view pattern recognition

  We have optimized all the code in the 2-view registration phase in terms of memory usage. The total memory consumption is grealy reduced while registering images, which should enhance performance when registering 100s of frames. We have also fixed a couple of minor inconsistencies in the engine that could have caused variable registration results, so variance is reduced meaning more robust results.

• IMPROVED 4)REGISTER, mosaic descriptor creation

  When running a very big mosaic (100+ frames) APP used to create all the descriptors for each frame first and then start registering the frames to each other. This implementation was rather memory hungry because all the descriptors were needed to stay in memory. It could cause systems to run Out Of Memory https://www.astropixelprocessor.com/community/main-forum/encountered-error-in-module-createqualityregistrationdescriptorstask/#post-34515. Beta45 will now only create the descriptors for a reference frame when needed and will remove it from memory immediately when it is no longer needed. In this way, memory consumption stays under control and the performance is not affected and might be slightly better on certain systems with big mosaics.

• IMPROVED 4)REGISTER, pattern recognition will be faster and use less memory

  We have made several optimizations in the 2-view registration phase where patterns between the stars are matched between the frames to be registered. The K-dimensional tree implementation was upgraded to be faster and use less memory.

• FIXED 4)REGISTER dynamic distorion correction was disabled on pierflipped data

  As mentioned here https://www.astropixelprocessor.com/community/main-forum/app-2-0-beta-41-registration-error/#post-34353 registration did not work properly on frames that were pierflipped. beta39-beta44 (new registration engine) mistakenly turned off dynamic distortion correction on these frames, but they clearly need it. This has been robustly fixed by adding an algorithm in the registration engine that detects a pier flip. 

• FIXED 4)REGISTER no more force of calibrated projective model for data that is near 200mm in focal length.

  As reported here https://www.astropixelprocessor.com/community/appreleases/beta-41-registration-issues/#post-34210 if the projective registration model was used on data that has a focal length near 200mm, the engine could warn the user that the calibrated projective model would be needed and it would force that model. That behaviour has been changed. The user will be asked now to continue with the projective model or if he/she wants to change the model. VIce versa also for starting with the calibrated projective model and possibly using the projective model when the mosaic calculation sees that projective is also viable.

• FIXED 4)REGISTER comet/one-star 

  As reported here https://www.astropixelprocessor.com/community/comet-registration-and-integration/beta-41-comet-registration-issues/#post-34307 the comet/one-star regisgtration mode had several issues with data that has little stars and low quality (shot in the morning glow). We have fixed 4 problems so now the data can be properly processed. We have fixed 2 bugs related to little stars so the images might not be able to register on the stars. We fixed the counter of which image is being processed in the comet mode and we also added a warning message if star registration is simply not possible and the user should try to disable star analysis and the register on the comet only.

• FIXED SAVE/LOAD Preferences

  Several issues have been fixed for saving and loading the user preferences between APP restarts. For instance, if APP starts with a crash for some reason, or if APP start is aborted before being fully loaded, the next APP instance could start with not default settings, like in 3) Analyse Stars, it could start with max stars of only 10. This has been fixed. If such an APP crash/abort occurs, APP will detect it the next time it is started and it will safely load all the default settings. 

• FIXED ArrayIndexOutOfBoundsException in LokationAndScaleCalculator for NormalizationMap

I keep every file that is produced by my astro gear, So this means that my AsiAir creates fits, and jpg's, as does my Seestar.    When start to add lights, darks, etc.   I have to manually change the filetype from all, to fits, to filter out the jpgs, and I have to do this every time I open the dialog.

I would love to be able to setup my own list of custom filters, as a default, so that I don't have to do this every single time.  Personally, for my needs I would like to be able to select *.fits, *.cr2, *.dng and that would cover me completely, pretty sure that others would want to request something else which would create a whole debate and endless back and fourth.   So, my thought is add a filter to the Licence & settings dialog, that if you fill it in, it becomes the default selection when importing files.  When importing files, a "custom" option is added to the file type list, as defined by the setting, and selected by default.   Users can then change this as desired.

Should be a fairly simple change that will allow people such as myself to be a little bit lazier, and happier at the same time.