UPDATE FROM MABULA
I have had a very rough 2 months unfortunately health wise. I was struck 3x in a row with bacterial infections. The second infection occurred after a routine hospital checkup and I became very sick. I had to rest and take a lot of antibiotics. Once I was recovering and restarting work 1 month ago, I again became sick. The infection was not yet gone, so even more antibiotics and rest was needed. Needless to say, it took a lot of my energy and I needed a lot of rest.
Finally, the infection is really gone and my energy is coming back step-by-step now and I have started work again. I am terribly sorry to have kept you waiting for support. I will address all outstanding questions and e-mails step-by step and will be on the forum daily from today.
APP 2.0.0-beta47 will come soon as well, a lot of work was already completed before I became very ill, so the release is also nearly ready for you. Beta47 will be much faster actually. Many workflows will be more than 2x faster, mosaics can even be 10x faster than before because registration really received a major boost... all compared to beta46. Before I release it, I will make sure that everything is working properly and then I will release it.
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
