I just tested beta 46 on Linux Mint. 100 frames of aps-c osc data.

Everything worked fine. Subjectively it felt a little faster than beta 45.

Memory management is certainly improved over beta 45. APP ram used never got much over 4gb  on my system. However, OS ram held still went to about 75gb. An improvement on beta 45, but not by much. My guess is that there still may be some scope for tuning the release of memory.

I'm running this on a gen5 ssd. I wonder whether the very fast disk access is not allowing enough spare time for garbage collection, but I'm probably talking rubbish here 😉 .

JC

• Improved Internal Memory configuration and improved performance as a consequence.

  The latest beta's all had changes relating to memory controls, that means how much memory APP can use, how much memory it will reserve for usage and how much memory will be released back to the Operating System while processing. We have done more testing and beta46 probably has the final optimized configuration going forward for the 2.0 stable release. Beta46 will use quite a bit less memory than beta 43,44,45. It will compact it's memory usage now using the Shenandoah garbage collector from the OpenJDK development platform. The compact mode ensures that while APP receives memory allocations, APP will immediately clean things up and release the memory if possible. So instead of APP using a big part (30-70 %) of the computer's memory, beta46 will show much less usage and as a consequence, it will show better performance. Using more memory can actually be a drag on performance it turns out. We see several % performance improvement because of this change in several benchmarks.

  All the optimizations that were implemented in the last year or so, gives APP a big performance boost and the old way of the memory controls that was used until beta39 became problematic. The memory could not be cleaned up in time because of the performance improvements, causing memory defragmentations and stalling of performance on big datasets. With Beta 46 this should definitely be a thing of the past and performance should continuously be good even on very big datasets.

• FIXED Set Save Directory

  2.0.0-Beta45 had a regression bug where setting the Save Directory did not work as expected. This has been fixed. It was reported here: https://www.astropixelprocessor.com/community/windows/problem-setting-save-directory-in-app-2-0-0-beta-45/#post-34703

• FIXED 2.0.0-beta45 startup issue

  Beta45 would not start on a computer that has less than 8 cpu threads. This has been fixed.

• FIXED ArrayIndexOutOfBounds Exception in SumSignalInCropWorker 

  As reported here https://www.astropixelprocessor.com/community/appreleases/beta-44-crashes-when-trying-to-register-existing-stacks/#post-34587 APP would throw an error in the SumSignalInCropWorker module if you try to normalize a multi-channel image with a monochrome reference image. This bug is a regression from previous optimizations and rewriting the normalization engine. It has now been properly fixed and you can normalize multi-banded images with a monochrome reference and vice versa.

• FIXED 2-panel mosaic works now in mosiac mode

  As reported here https://www.astropixelprocessor.com/community/main-forum/2-panel-mosaic-error/#post-34674 it you would try to register a 2-panel mosaic in the mosaic mode, it would error with an ArrayIndexOutOfBoundsException. The data could still be registered though in normal mode. The mosaic mode works now as well.

I was able to RGB Combine the R-G-B Mono camera channels with the R-G-B channels split from my OSC camera image using RGB2 without issue. 

But the RGB Combine using RGBHOO or RGBHSO fails. 

Also when I remove all the RGB channels and attempt to RBG Combine the H-S-O channels I get the same error (those are 100% from the same image train).  

I stacked and registered all these data in APP - it's just the RGB Combine that is failing.  

A bug in v45 is preventing normalisation of 3 frames (Ha, OIII and RGB Composite).  When clicking OK it just cycles through error messages and I have to kill the process in Windows Task Manager.  I have beta v13 installed on a laptop for when I'm travelling and this doesn't throw the issue and is able to normalise the data and save the frames OK so I don't think its the data.

I did a test a couple of years ago comparing different stackers on the same set of data.
50 frames shot with Nikon D5500 (NEF files).
Results:
Siril - 2:30m (fastest)
DSS    - 5m
ASTAP - 6m
APP     - 8m (lowest noise)
PI       - 21m

I just re-ran APP (latest 2.0 b45) - 7m - certainly not slower but a little bit faster.    

I have a Vaonis Vespera Pro.

I attempted my first stack with APP and failed at the integration stage.  I received three consecutive error messages all referrring to insufficient RAM.  I have 32 GB of RAM which I know ordinarily to be enough.  I tried reducing the scale right down but this did not solve the issue.  After the third error message there is a bell sound and the integration fails.  

I then changed to a completely diffrent data set for a different target.  This time the FOV size was 10000 x 11000 and would have needed 805 GB of hard disk space to integrate.

I seem to have a problem with the FOV size post Registration.

Can somebody please help as I cannot get beyond registration currently due to the FOV size.

Thank you

Hi

The attached stacked image is produced by stacking 60 frames with dark, bias and flat using an ASI 2600MC and Celestron edge 11". As you can see the image is dominated by an intense green color difficult rot remove in post processing. If I check the "neutralize background box , the background turns red. Can you please help?

sandro