Please note our new Downloads page here
2023-01-19: APP 2.0.0-beta13 has been released !
!!! Big performance increase due to optimizations in integration !!!
and upgraded development platform to GraalVM 22.3 based on openJDK19
We are very close now to releasing APP 2.0.0 stable with a complete printable manual...
Astro Pixel Processor Windows 64-bit
Astro Pixel Processor macOS Intel 64-bit
Astro Pixel Processor macOS Apple M Silicon 64-bit
Astro Pixel Processor Linux DEB 64-bit
Astro Pixel Processor Linux RPM 64-bit
Hello,
how far are the developments concerning greater mosaics with APP?
A while ago APP had difficulties managing this and often forced (me) to downscale mosaics. Rather bad when this is NOT why doing mosaics: loosing resolution. Can APP for examples use swap files meanwhile?
I want to process 24 panels of 61 mp each, of a 6200mm..
Stefan
Hi,
Same question here.
According to the pop up message from APP, the current technical limit for a mosaic is 715 megapixels before downscaling the resulting mosaic.
Can you explain this limitation ?
David
I found my old request:
answer is still due 🤓 😜
I checked with Mabula. It indeed still is on the TODO list and will not be part of APP 2.0.0.
too bad.. so this means another 2 years plus? 😬 🍹
(Mosaics are one of THE features of APP, right? Cam's have more resolution ...)
Hi Stefan @elgol & David @dav78,
Our old development platform had a technical limit in such that the image could never be larger than 2^31 = 2GigaPixels... and this holds for mono. For RGB, since you have 3 channels, the limit is 2GigaPixels divided by 3 = roughly 715 megapixels.
Now, with our new and updated development platform, I will see if we can overcome this technical limit. It is on the ToDo.
I also need to revise the preview filter which is also on our ToDo, so it will be easier in terms of RAM memory to load and see such an image if RAM is not sufficient.
APP is already using swap files, so that is not the issue here. Another issue is that you want to see the image with OpenGL/GPU hardware rendering, now most videocards do not allow for texture sizes that big simply. So the OpenGL image viewer needs to be updated as well to use multiple textures if such a big image is loaded. The current behaviour is that it now falls back to CPU rendering, and then you need all pixels in RAM to make it work in such a way that you can still zoom in/out nicely, see all details without having big loss of performance. If you would use swapping, it will be much slower of course.
So we need to conquer differnent problems to make this easier, and all are definitely on our ToDo goin forward, not having mentioned even that the mosaic algortihms will be greatly improved as well as will the registration engine 😉
We have a lot of work ahead !
Mabula
@mabula-admin Great Mabula! And I really feel a big difference in overall speed with 2.0.... 👍
Thanks for the explanations @mabula-admin
Let's see if you can manage to improve this technical limit 👍
David