Mar 28 2026 APP 2.0.0-beta40 will be released in 7 days.
It did take a long time to have the work finished on this and it will have a major performance boost of 30-50% over 2.0.0-beta39 from calibration to integration. We extensively optimized many critical parts of APP. All has been tested to guarantee correct optimizations. Drizzle and image resampling is much faster for instance, those modules have been completely rewritten. Much less memory usage. LNC 2.0 will be released which works much better and faster than LNC in it's current state. And more, all will be added to the release notes in the coming weeks...
Update on the 2.0.0 release & the full manual
We are getting close to the 2.0.0 stable release and the full manual. The manual will soon become available on the website and also in PDF format. Both versions will be identical and once released, will start to follow the APP release cycle and thus will stay up-to-date to the latest APP version.
Once 2.0.0 is released, the price for APP will increase. Owner's license holders will not need to pay an upgrade fee to use 2.0.0, neither do Renter's license holders.
OK, I figured out that this mosaic-calculation works without trouble when running on 2x 6-core and 2x 8-core. But this Java-error pops up again when I use 2x 14-core. Tested on Intel Xeon and Windows 10 Pro.
Very strange...
I have ran this on my dual Xeon setup with no problems, but it only uses one of the processors, not both for some reason. Mine is a dual E5-2696v4 with 256gb ram and an RTX 4090 gpu. Also uses 2x 2tb nvme SSDs and it runs witndow 10 pro. The processors are 22 cores/44 threads each.
What generation of Xeon processors are you running, and have you installed all of the optional Windows updates too?
Yes, OS is up to date.
All mentioned hardware is able to run a normal integration, these problems arise only when calculating this big mosaic with more than 32 CPUs enabled.
Tested:
2x Xeon X5690 with 192 GB RAM (2x 6-core, no problems here)
2x XEON E5-2620 v4 with 512 GB RAM (2x 8-core, no problems here)
2x XEON E5-2680 v4 with 512 GB RAM (2x 14-core, Java Error with Hyperthreading enabled, without no problem but slow)
The same seems to apply for Linux.
APP's working directory is on a fast 4TB NVME, OS is on a 1TB SSD.
That is strange because I've gotten good size mosaics done no problem on both of my computers with the only problem being when I try to do an RGB combine and getting an error that I need to reduce the file sizes.
When you do mosaics are you stacking only the master lights for each individual panel?
Of course only master-lights are used.
But from an OSC camera, so the size-limitation is hitting hard with more than 50% automatic downscale after registration.
Would be helpful if Mabula could join and look into this.
I am about to do a mosaic with 30 master lights each or Ha, Sii, and Oiii for a total of 90 masters and 30 panels and I hate how much I am going to have to downsample this. It will be even worse if I decide to add in 5 or 10 more panels each of SHO bringing in another 15 or 30 master lights.
When the app started downsizing my image, I was also annoyed, but now my computer would no longer be able to edit the image if it had the full resolution.
After building a new old server with 2 CPUs and 28 cores I was able to test all this also Windows 11.
Same behavior here:
With more than 32 threads enabled in APP the final integration task crashes at the end with the mentioned Java error.
I can use all 56 threads until APP tells me that it will scale the image down. Then I have to dial down the CPU-usage to 32 threads for APP to finish the integration with an image as a result, otherwise it will get an error.
@walsc Can I ask you for a detailed list of components apart from the processor? What motherboard did you use and what RAM?
@elwis My last test was on a HP Proliant DL 380, Mainboard and RAM from HP.
As this problem occured on four different machines, I assume it is not related to hardware.
I have this on Windows 10, Windows 11, Mint Linux, Gentoo Linux.
The server vendors are Supermicro, HP, Quanta Grid.
Tested CPUs: Intel XEON E5 2640v4/2667v4/2690v4 and AMD EPYC 7551 - all with dual-socket configuration.
Hi Walter @walsc,
I have read most of this topic now and will provide support again going forward, Please accept my apologies for letting you in the dark here.
So can I conclude now that the issue is definitely caused by enabling more than 32 CPU Threads? Then a certain error message is always thrown for an array out of bounds somewhere?
Do you have this error message for me? Can you test it one more time with the 2.0.0-beta30 version which was just released? That error message would immediately tell me where the problem is so I can fix it a.s.a.p..
Mabula
@mabula-admin OK, thank you, I am starting the machines.
I somewhere at the start of this thread I mentioned the error-message. This occured somewhere in the progress of this huge mosaic, not in the beginning.
I will be back with results.
Hi Walter @walsc,
Thanks, and yes, I have the error message from earlier in thread now. Thanks.
These Error-message is given on the EPYC-machine, no matter if Windows or Linux installed.
And this error always comes at the end of the integration-process, only on this computer.
I have already checked the code there and I can probably understand why this error occurs with more than 32 CPU threads.
I will try to solve this a.s.a.p. now and will provide a test version with a possible fix.
Mabula
So, I performed the mosaic calculation again in Beta 30 without reducing the amount of threads. As expected, the same error message as above occured.
System:
Windows 11
2x Intel XEON E5-2690V4 (2x 14-core/28thread)
768 GB DDR4 reg.ECC
4 TB NVME
Hi Walter @walsc,
Thank you very much, okay, this is the issue at the top of my list now. I will report back later, when I should have a solution for the issue.
Mabula
Hi Walter @walsc,
Can you check the following information in the general console panel for me, when the actual integration tasks starts, and report to me what the reported values are? That should really help me solve this.
When the integration tasks starts, you will always see output in the console panel like this when the first frame/sub of the stack is loaded:
using read buffer per thread of xxxx KiloBytes
using total read buffer of xxxx KiloBytes
integration buffer consumes xxxx MegaBytes of RAM memory
What are the values of xxx with 64 CPU threads enabled?
Thanks!
@mabula-admin OK, I will run it again, results tomorrow night.
But this machine has max. 56 threads (2x 14 core), more is not available any more, I sold some stuff.
Hi Walter @walsc,
Thank you very much for the requested info. I will get back to you soon with more feedback from my part with a solution hopefully.
Mabula
Hi Walter @walsc and everyone else involved in this topic @dheyergmail-com @artem @imnewhere @elwis
I think I have found the problem in our code that creates this ArrayIndexOutOfBoundsException (for the mosaic) with more than 32 threads.
Our concurrency code in the integrator cycles over the pixels, the number of channels (R,G,B or mono), and the number of CPU threads using read and write buffers of 4kB per cpu thread. In the cases when the actual data size approaches 2GB, this error can be thrown depending on the details of the actual task, i.e. the number of CPU threads involved and the exact size in pixels of the output integration file.
It is weird that the error pops up on Windows, but not on MacOS, right? I think the development platform (Java/GraalVM) has slight differences in behaviour per platform, at least that would explain it. Maybe this bug fix will actually also fix the issue with the stripes on the Macs then I think... On the macs, an error does occur, is not reported for some reason and it keeps going leaving some data parts not integrated causing those stripes...
I will build a test version in the coming hour and will let you know soon where you can download it 😉
Mabula
Hi Walter @walsc,
Can you please try this test version and let me know if all is okay now regarding this ArrayIndexOutOfBounds error on Windows?
Please note, this test version is not digitally signed, so Windows may complain that it is not safe. Apart from the signing, nothing else is different than the regular releases. Tomorrow evening, I am home again and will be able to make a signed test version if required.
APP version 2.0.0-beta31-test for Windows:
Thanks,
Mabula
@mabula-admin Thank you, my machine is starting up.
I'll be back tomorrow night with some result.
@mabula-admin Thank you, my machine is starting up.
I'll be back tomorrow night with some result.
Great ! I will be looking out for your result 😉
Hi Walter @walsc,
That is awesome! Thank you very much for testing this so quickly. I am very happy that this one is solved properly now.
I will soon release beta31, first we will also test the issue with APP not detecting all the threads/NUMA. I will try to make that test version for all platforms today including this fix of course.
Mabula
