Hey, after working on it for the last 1.5 week, finally I was able to build and run *Hugin 2022.1.0* on my *M1* natively (*aarch64/arm64*). But, *nona* is still failing to merge my *OpenEXR*'s in some cases.
I had to use: - boost 1.81.0 - exiv2-0.27.6 - gettext-0.21.1 - glib-2.76.1 - openexr-v2.5.8 (as I understand 3.1.7 has breaking changes) - libffi-3.4.3 - openmp-16.0.1 and had to update nearly all the build scripts under *mac/ExternalPrograms/scripts*, also somehow the *libboost_atomic.dylib* is not getting included by the packaging script, I had to update the *PackageMacAppBundleLibs.sh* to copy it manually for each app. I'll keep working on it, if anyone wants to try it you can download it from this link: https://www.dropbox.com/sh/u1t2thzv3bb45xn/AAB16jItGM8ZkumJg8eXPsL5a?dl=0 One more thing, I also included *"libboost_atomic.dylib"*, put it in to *"/usr/local/lib/"* Erkan Ozgur Yilmaz On Sunday, 9 April 2023 at 15:41:42 UTC+1 dud...@gmail.com wrote: > Hi! > Yes, its says ping pong rendering, not familiar with this concept. > > I changed the numbers and it works so far. It´s nothing I would assume > would be used in main source. My contribution here is of open source value > for anybody getting similar issues or for the code author or anyone else > interested in this to look into changing or refine code. Maybe even I will > have a deeper look, idk. Questions are valid though. Is the code doing more > harm than good etc. Both original and my blind fix. > By the way. A few places with "fixme" in *ImageTransformsGPU.cpp* and > where the coder simply commented out code after testing for speed reason > not really knowing the cause of the behaviour so I am not completely alone > in the world accepting irregularities here :). > > Seems I have arrived quite late to hugin party and I am grateful that I at > least could get some sort of contact with you and Max. Really nice program > and the enfuse/align has meant a lot to a lot of photographers out there. > Really cool stuff. > /Daniel > > söndag 9 april 2023 kl. 16:05:24 UTC+2 skrev T. Modes: > >> dud...@gmail.com schrieb am Sonntag, 9. April 2023 um 11:16:36 UTC+2: >> >> Hi. Are these numbers applied also to at/nvidia cards or do they apply >> only for other cards not defined? If applied globally tests show no benefit >> having larger dest chunks like 16 + 16 + 8. >> More testes shows too high negative numbers will hang processing, while >> too high, as we know corrupts framebuffering. >> Question remains. Could code be made more robust removing or changing >> behaviour in this particular place? >> >> You can't simply change randomly numbers and hope that this fixes it. The >> meaning of the number is written directly above the line in the comment. >> >> >> By the way. What is the real cause of the issue here? >> >> I assume that it reads only the first dest chunk correctly back. The >> second and further one are not correctly read back. But I don't know why it >> works on most systems except the M1 one. Apple must have something special >> in its implementation. >> > -- A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ --- You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group. To unsubscribe from this group and stop receiving emails from it, send an email to hugin-ptx+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/8fe781e1-42a4-4fe6-af44-3cea945232fdn%40googlegroups.com.
