Mac builds of Hugin

[Max Mueggler]

I built the 2021 and pre-release-2022 Hugin versions for MacOS, as the latest official build is from 2019. They're at https://drive.google.com/drive/folders/1MwEOlVTQx6R7ay-LJPYxSraytxDzCOUZ.

[dgjohnston]

Max, thanks very much for building these. I’ve done a preliminary test on the 2021 build on my MacBook Pro with M1 chip and it seems to be working great.

Don J.

On Jun 16, 2022, at 7:25 PM, Max Mueggler <maximums...@gmail.com> wrote:

I built the 2021 and pre-release-2022 Hugin versions for MacOS, as the latest official build is from 2019. They're at https://drive.google.com/drive/folders/1MwEOlVTQx6R7ay-LJPYxSraytxDzCOUZ.

--
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+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/b55742c1-b890-4e7b-a4e8-c0f6fac59952n%40googlegroups.com.

[dgjohnston]

Also just tested the 2022 prerelease (MacBook Pro with M1 chip).

Would run … got a message "The application “Hugin.app” can’t be opened. -47”.  I was however able to the Hugin from the “Contents/MacOS”.

Seemed to run good after that.

Thanks again Max.

Don J.

On Jun 16, 2022, at 7:25 PM, Max Mueggler <maximums...@gmail.com> wrote:

I built the 2021 and pre-release-2022 Hugin versions for MacOS, as the latest official build is from 2019. They're at https://drive.google.com/drive/folders/1MwEOlVTQx6R7ay-LJPYxSraytxDzCOUZ.

[Max Mueggler]

That's interesting. These builds are for x86, so the error might have something to do with Rosetta.

 -Max

[Don Johnston]

Yes you never know when you're trying to emulate a different chip set. But your 2021 build worked fine.

Don J.

[dudek53]

Thanks a lot for the compiled builds for macbook pro M1. I gotta aska very specific question. Could you guys reporoduce a potential issue around align_image_stack? Every time I enable --gpu when trying to align images directly in terminal on my mac I get corrupted files. Could anybody test in terminal:
align_image_stack -a drag/three/images/here --gpu then ENTER. Output will give half images or corrupted images. Something is going on with gpu but unclear what. Maybe could be fixed?

[T. Modes]

dud...@gmail.com schrieb am Dienstag, 7. März 2023 um 17:26:11 UTC+1:

Thanks a lot for the compiled builds for macbook pro M1. I gotta aska very specific question. Could you guys reporoduce a potential issue around align_image_stack? Every time I enable --gpu when trying to align images directly in terminal on my mac I get corrupted files. Could anybody test in terminal:
align_image_stack -a drag/three/images/here --gpu then ENTER. Output will give half images or corrupted images. Something is going on with gpu but unclear what. Maybe could be fixed?

There is a problem with the command line: the -a switch expect the prefix as argument.

So the command line should be

align_image_stack -a prefix --gpu drag/three/images/here

 Does this happens will all image set or only with a single one? If this happens only for a single one (after fixing the command line as above) please provide the sample images, so we can check more.

 

[dudek53]

Hi! Thanks a lot for getting back. Tested with correct prefix syntax but issue persists.

Happens on all three images. Looks like follows:

https://i.postimg.cc/cLXBVc9s/test0000-tif-300px.jpg
https://i.postimg.cc/430b3xRq/test0001-tif-300px.jpg
https://i.postimg.cc/PqJQh891/test0002-tif-300px.jpg

My testfiles here:

https://bitbucket.org/Dannephoto/mlv_app_compiler-git/downloads/DJI_0946.JPG

https://bitbucket.org/Dannephoto/mlv_app_compiler-git/downloads/DJI_0947.JPG

https://bitbucket.org/Dannephoto/mlv_app_compiler-git/downloads/DJI_0948.JPG

History. This gpu issue started on recent M1 machines. Early 13 inch models did not have this issue. Could be memory related. I could try and seek for error messages thorugh console again. I think I triggered an issue around framebuffer testing one version a while back ago.

So sorry for these vague descriptions but I will give more info when I have more time.

Thanks

/D

[T. Modes]

Hi,

dud...@gmail.com schrieb am Dienstag, 7. März 2023 um 18:31:24 UTC+1:

Hi! Thanks a lot for getting back. Tested with correct prefix syntax but issue persists.

History. This gpu issue started on recent M1 machines. Early 13 inch models did not have this issue. Could be memory related. I could try and seek for error messages thorugh console again. I think I triggered an issue around framebuffer testing one version a while back ago.

So sorry for these vague descriptions but I will give more info when I have more time.

I tested under Windows with 2 different graphic cards. In all cases the results are ok.

So it seems no general problem in align_image_stack. But without access to such a failing machine or further informations it is very difficult to debug.

[dudek53]

Hi and thanks for testing. This problem is specific for Mac M1.

One version will trigger this issue:

nona: Unsupported framebuffer format in: /Users/_matthieu_/Sources/Hugin/2014/0/release/src/hugin_base/vigra_ext/ImageTransformsGPU.cpp:738

I really want to fix this and it would be very nice to attract someone here that might be able and reproduce the issue. I see a lot of knowledge and even people compiling on M1 machines so I am confident this might be possible to fix :).

[dudek53]

Hi! I did some more research here and I also triggered some error log which I put into pastebin for viewing.

https://pastebin.com/uhnbA5Jr

I also notice following. Reducing file size to around 3000 pixels from 4000 pixels processes the file just fine with --gpu enabled. So I guess size matters here? Maybe related to some race condition in graphic card/memory? Only speculating here.

Also triggered debug log message: narrowing channel width for output as "uint8"

What you say T. Modes? you seem to be well aquinted with code around here :).

Regards

/Daniel

[T. Modes]

dud...@gmail.com schrieb am Sonntag, 12. März 2023 um 18:22:14 UTC+1:

Hi! I did some more research here and I also triggered some error log which I put into pastebin for viewing.

I also notice following. Reducing file size to around 3000 pixels from 4000 pixels processes the file just fine with --gpu enabled. So I guess size matters here? Maybe related to some race condition in graphic card/memory? Only speculating here.

Also triggered debug log message: narrowing channel width for output as "uint8"

Sorry, but I'm lost. First there are corrupted images, then it crashes.  

Next time you post debug messages from a 2014 version.

Then you mentioned unsupported framebuffer format. This issue was fixed in 2016.0.

So each time the error changes, this makes it hard to do anything substantial.

[dudek53]

Sorry about the confusion. I am using a workflow which integrates some older versions in lightroom. I am presenting the lightroom workflow as it triggers an error log on my mac. A log which is not triggered when running align_image_stack on command line directly.

My conclusion is that too big files will trigger the issue and in lightroom aligning will be skipped. If files are below 3000 pixels all is working with --gpu enabled.

THis is the error log triggered when testing in lightroom. In this error log I am using the official binaries from 2019 taken from here Hugin-2019.2.0.dmg:

https://pastebin.com/86LH3W52

Oki, the other attempt is when working from command line. I am know in Hugin application itself and I am testing:

align_image_stack -a prefix --gpu drag/three/images/here

This is giving those corrupted halfwritten files . However. I am then testing reducing my test fiels to around 3000pixels. This actually works and --gpu will then produce correct files. So THis is how far I have come around the issue. I can verify at least three more users with these issues on M1 graphics card. Is there anything we could test here :)? All tests has now been performed with Hugin-2019.2.0.dmg.

 And again! Thanks for this program. I love it.

[T. Modes]

dud...@gmail.com schrieb am Mittwoch, 15. März 2023 um 19:23:56 UTC+1:

Sorry about the confusion. I am using a workflow which integrates some older versions in lightroom. I am presenting the lightroom workflow as it triggers an error log on my mac. A log which is not triggered when running align_image_stack on command line directly.

My conclusion is that too big files will trigger the issue and in lightroom aligning will be skipped. If files are below 3000 pixels all is working with --gpu enabled.

THis is the error log triggered when testing in lightroom. In this error log I am using the official binaries from 2019 taken from here Hugin-2019.2.0.dmg:

The log indicates a problem with reading back the data from the GPU. This matches with the corrupted images.

Align_image_stack has no more debug possibilities for GPU remapping. Here we have to use nona.

Try the following:

1. Create a pto file with align_image_stack

align_image_stack -p test.pto drag/three/images/here

2. Then remap the image with nona. Activate gpu remapping and debug output

nona -o test --gpu --debug test.pto

Then provide the output of nona to the terminal (The resulting images should be corrupted again. If not the problem is somewhere other. Please check this.)

The easiest way would be to redirect the output to test file and provide this text file

nona -o test --gpu --debug test.pto >test.txt

Please provide also the pto file. Ideally use the already provided test images (DJI_0946.JPG ...)

[dudek53]

Cool!

Issue with corrupted fikes reproduced with nona command:

nona -o test --gpu --debug test.pto

Terminal output:

https://pastebin.com/UZLUTS5z

I used the old test files.

.pto file here:

https://bitbucket.org/Dannephoto/mlv_app_compiler-git/downloads/test.pto

Any clues?

[T. Modes]

dud...@gmail.com schrieb am Mittwoch, 15. März 2023 um 20:22:56 UTC+1:

Cool!

Issue with corrupted fikes reproduced with nona command:

nona -o test --gpu --debug test.pto

Terminal output:

I had a look at the output. But I don't see any obvious errors. The information looks very close on my side.

So I don't understand what happens here. But I'm no OpenGL expert. The code was written by  Andrew Mihal, and I maintain it only.

It seems Apple OpenGL implementation is slightly different in details from Windows/Linux one. But no idea what more to check.

The only workaround would be to remove the --gpu switch and do the remapping on the CPU.

 

[dudek53]

Or port OPenGL to use Metal :). A quick search shows non support for OpenGL. I guess this could cause issues.

https://developer.apple.com/forums/thread/694866

--

A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ
---

You received this message because you are subscribed to a topic in the Google Groups "hugin and other free panoramic software" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/hugin-ptx/cAzcl7HaQs4/unsubscribe.
To unsubscribe from this group and all its topics, send an email to hugin-ptx+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/8ebc04e6-2b61-4280-a9bc-45a125eef481n%40googlegroups.com.

[T. Modes]

dud...@gmail.com schrieb am Samstag, 18. März 2023 um 03:25:15 UTC+1:

Or port OPenGL to use Metal :). A quick search shows non support for OpenGL. I guess this could cause issues.

If you (or somebody) rewrite the whole code…

And Metal is Apple only. It will not work on Linux and Windows.

[dudek53]

Yup. Not opimal at all. Mac philosophy sometimes :(.

At least there´s some direction now what to do if and when that will happen :).

Big thanks for you help here meanhwile.

/Daniel

[Max Mueggler]

On my 2015 dual-gpu Mac, I got corrupted images when remapping with the integrated (Intel) GPU forced, but correct images when nona was allowed to use the dedicated (AMD) GPU.

From what I remember from the small amount of OpenGL programming I did on that machine, the AMD drivers were looser with extreme values plugged into transcendental functions, whereas the Intel drivers were quicker to return NaN or Infinity. Perhaps that has something to do with it.

[dudek53]

Hehe, this is beyond the scope of my horizon atm. I tested your compilations first when I got here hoping this would fix the issues since you compiled on M1.

Could you maybe test on your worksation if it´s working on your end or not with the provided test files? Since it is semiworking here with smaller files I am not sure if they remove libraries after Big Sur or if it is because of lack of virtual memory or what not on later macbook pros.

I played around with a pto file created in nona and it was able to spit out a b&w pgm file and I could also reduce size directly in the pro file but other than that I coudl not get any more clues.

By the way. How hard is it to get compiling working on mac m1? I am failing miserably over here. makefiles and sources all seem to be using older mac architecture.

[dudek53]

Hi. Maybe I see something here. In my provided testfile created with nona I get successfull gpu exports when reducing widht and height destination size straight into the pro file:

In test.pto I have at the top:

# hugin project file
#hugin_ptoversion 2
p f0 w4000 h3000 v71.5915  E12.2928 R0 n"TIFF_m c:LZW"

Change it to:

# hugin project file
#hugin_ptoversion 2
p f0 w3700 h2750 v71.5915  E12.2928 R0 n"TIFF_m c:LZW"

And output is ok. No corrupted half frame.

https://pastebin.com/t6yMfcc8

Upon inspection of the output comparing debug log it seems issues are all happening around gpu dest chunk

For instance this place:

Source chunks:
    [(0, 0) to (4000, 3000) = (4000x3000)]
Dest chunks:
    [(0, 0) to (3704, 2750) = (3704x2750)]
Total GPU memory used: 532184000

Leads to:

gpu shader program compile time = 0.014
gpu shader texture/framebuffer setup time = 0.001
gpu dest chunk=[(0, 0) to (3704, 2750) = (3704x2750)] coord image render time = 0.049
gpu dest chunk=[(0, 0) to (3704, 2750) = (3704x2750)] source chunk=[(0, 0) to (4000, 3000) = (4000x3000)] src upload = 0.037
gpu dest chunk=[(0, 0) to (3704, 2750) = (3704x2750)] source chunk=[(0, 0) to (4000, 3000) = (4000x3000)] src render = 0.004
gpu dest chunk=[(0, 0) to (3704, 2750) = (3704x2750)] source chunk=[(0, 0) to (4000, 3000) = (4000x3000)] interpolation chunk=[(0, 0) to (4, 4) = (4x4)] setup = 0.009
gpu dest chunk=[(0, 0) to (3704, 2750) = (3704x2750)] source chunk=[(0, 0) to (4000, 3000) = (4000x3000)] interpolation chunk=[(0, 0) to (4, 4) = (4x4)] render = 0.014
gpu dest chunk=[(0, 0) to (3704, 2750) = (3704x2750)] normalization setup = 0
gpu dest chunk=[(0, 0) to (3704, 2750) = (3704x2750)] normalization render = 0.004
gpu dest chunk=[(0, 0) to (3704, 2750) = (3704x2750)] dest rgb disassembly setup = 0
gpu dest chunk=[(0, 0) to (3704, 2750) = (3704x2750)] dest rgb disassembly render = 0.003
gpu dest chunk=[(0, 0) to (3704, 2750) = (3704x2750)] rgb readback = 0.004
gpu dest chunk=[(0, 0) to (3704, 2750) = (3704x2750)] dest alpha disassembly setup = 0
gpu dest chunk=[(0, 0) to (3704, 2750) = (3704x2750)] dest alpha disassembly render = 0.003
gpu dest chunk=[(0, 0) to (3704, 2750) = (3704x2750)] alpha readback = 0.002

Above is an example of a successful gpu processing.

Then back to the problematic one:

log file:

https://pastebin.com/BmFD6XMb

In the problematic test let´s keep following:

In test.pto I have at the top:

# hugin project file
#hugin_ptoversion 2
p f0 w4000 h3000 v71.5915  E12.2928 R0 n"TIFF_m c:LZW"

In the log already we can see a potential conflict:

Testing texture size 16384, result=16384
maxTextureSize=16384
Source chunks:
    [(0, 0) to (4000, 3000) = (4000x3000)]
Dest chunks:
    [(0, 0) to (2000, 3000) = (2000x3000)]
    [(2000, 0) to (4000, 3000) = (2000x3000)]
Total GPU memory used: 348000000

Dest chunk should be 4000, 3000 not as nothing was changed here. T.Modes. How are your ouput here?

proceeding in the log we see the same issue

gpu shader program compile time = 0.014
gpu shader texture/framebuffer setup time = 0.001
gpu dest chunk=[(0, 0) to (2000, 3000) = (2000x3000)] coord image render time = 0.008
gpu dest chunk=[(0, 0) to (2000, 3000) = (2000x3000)] source chunk=[(0, 0) to (4000, 3000) = (4000x3000)] src upload = 0.038
gpu dest chunk=[(0, 0) to (2000, 3000) = (2000x3000)] source chunk=[(0, 0) to (4000, 3000) = (4000x3000)] src render = 0.003
gpu dest chunk=[(0, 0) to (2000, 3000) = (2000x3000)] source chunk=[(0, 0) to (4000, 3000) = (4000x3000)] interpolation chunk=[(0, 0) to (4, 4) = (4x4)] setup = 0.006
gpu dest chunk=[(0, 0) to (2000, 3000) = (2000x3000)] source chunk=[(0, 0) to (4000, 3000) = (4000x3000)] interpolation chunk=[(0, 0) to (4, 4) = (4x4)] render = 0.009
gpu dest chunk=[(0, 0) to (2000, 3000) = (2000x3000)] normalization setup = 0
gpu dest chunk=[(0, 0) to (2000, 3000) = (2000x3000)] normalization render = 0.002
gpu dest chunk=[(0, 0) to (2000, 3000) = (2000x3000)] dest rgb disassembly setup = 0
gpu dest chunk=[(0, 0) to (2000, 3000) = (2000x3000)] dest rgb disassembly render = 0.002
gpu dest chunk=[(0, 0) to (2000, 3000) = (2000x3000)] rgb readback = 0.004
gpu dest chunk=[(0, 0) to (2000, 3000) = (2000x3000)] dest alpha disassembly setup = 0
gpu dest chunk=[(0, 0) to (2000, 3000) = (2000x3000)] dest alpha disassembly render = 0.002
gpu dest chunk=[(0, 0) to (2000, 3000) = (2000x3000)] alpha readback = 0.001
gpu dest chunk=[(2000, 0) to (4000, 3000) = (2000x3000)] coord image render time = 0.002
gpu dest chunk=[(2000, 0) to (4000, 3000) = (2000x3000)] source chunk=[(0, 0) to (4000, 3000) = (4000x3000)] interpolation chunk=[(0, 0) to (4, 4) = (4x4)] setup = 0.001
gpu dest chunk=[(2000, 0) to (4000, 3000) = (2000x3000)] source chunk=[(0, 0) to (4000, 3000) = (4000x3000)] interpolation chunk=[(0, 0) to (4, 4) = (4x4)] render = 0.002
gpu dest chunk=[(2000, 0) to (4000, 3000) = (2000x3000)] normalization setup = 0
gpu dest chunk=[(2000, 0) to (4000, 3000) = (2000x3000)] normalization render = 0.001
gpu dest chunk=[(2000, 0) to (4000, 3000) = (2000x3000)] dest rgb disassembly setup = 0
gpu dest chunk=[(2000, 0) to (4000, 3000) = (2000x3000)] dest rgb disassembly render = 0.001
gpu dest chunk=[(2000, 0) to (4000, 3000) = (2000x3000)] rgb readback = 0.013
gpu dest chunk=[(2000, 0) to (4000, 3000) = (2000x3000)] dest alpha disassembly setup = 0
gpu dest chunk=[(2000, 0) to (4000, 3000) = (2000x3000)] dest alpha disassembly render = 0.002
gpu dest chunk=[(2000, 0) to (4000, 3000) = (2000x3000)] alpha readback = 0.002
gpu destruct time = 0.005

Any thoughts on this?

/Daniel

[dudek53]

Hm, I answer my self on this. Seems ok and expected. I tested the same issue on an intel mac and the log seems similar at least. the reduced 2000x3000 size seems ok at least.

Here is a successful log from my intel mac:

https://pastebin.com/BmFD6XMb

From the successful intel machine

Now I see some difference in the beginning:

nona: using graphics card: NVIDIA Corporation NVIDIA GeForce GT 750M OpenGL Engine

destStart=[0, 0]

destEnd=[4000, 3000]

destSize=[(4000, 3000)]

srcSize=[(4000, 3000)]

srcBuffer=0x7f9d97300000

srcAlphaBuffer=0x0

destBuffer=0x7f9d99556000

From the not successful M1 machine:

nona: using graphics card: NVIDIA Corporation NVIDIA GeForce GT 750M OpenGL Engine

destStart=[0, 0]

destEnd=[4000, 3000]

destSize=[(4000, 3000)]

srcSize=[(4000, 3000)]

srcBuffer=0x7fee6ca00000

srcAlphaBuffer=0x0

destBuffer=0x7fee78000000

If anyone wants to test fixing this please shout out :).

[Max Mueggler]

Follow the instructions in mac/README.md. The biggest thing here is
compiling the external programs. I made a patch file with all the
changes I made to get them to download and build correctly, which I've
attached to this email. You might need to make more changes to e.g.
outdated URLs.

Unfortunately, it's been a while since I tried to do this, so there
might be caveats I'm not remembering. If you run into trouble, I can try
and help.


On 3/30/23 06:40, dudek53 wrote:
> Hi! I am interested to know more about compiling for mac. You seem to
> have got that going. I was hoping to get it to compile on my Macbook
> pro M1. Do you have any hints or is it ok if I ask you along the way
> about how to go on with compiling? My goal is to fix the graphic card
> glitch when enabling --gpu.
> All the best
> /Daniel

[T. Modes]

Hi Max,

maximums...@gmail.com schrieb am Freitag, 31. März 2023 um 23:28:51 UTC+2:

I made a patch file with all the
changes I made to get them to download and build correctly, which I've
attached to this email. You might need to make more changes to e.g.
outdated URLs.

Thanks for the patch. I committed these changes to the repository.

Next time please create the patch file as unified diff against the root directory of the repository instead of the mac subdirectory.

I had do to some modification before the patch applied cleanly.

Thomas

[dudek53]

Tested download-all.sh script. All downloaded except exiftool which lands a package of around 300 bytes. Could be fixed with replacing to this:

https://exiftool.org/Image-ExifTool-12.59.tar.gz

Anyway. Spent whole day trying to get things compiing on Big sur intel mac. Phew. Hard one. I need to look deeper than usual here ;).

Is it by the way possible to compile only align_image_stack and not havint oto compile the whole program or is everything chained?

[dudek53]

Hi again :). Progress has been made. First I compiled, at least align_image_stack and nona, on my intel mac, but gave up on that station and wnent to my M1 hoping it would solve the gpu issue. Managed to get a devenvironment running by updating makefiles and checking each dependency in the mac script and modernized downloads accordingly. Still not getting 100% configuration with those sources but when lacking I could run brew install so with a sort of a hybrid system it now compiles and I get so far as sudo make install and it makes the Hugin.app but then it stops. Good enough for know.

Fix

Fixing the --GPU issue. I actually found out where the trouble starts and fixed the issue inside ImageTransformsGPU.cpp so now I get corruption free output when --gpu is enabled. I still need some tinkering to get it nice in code but what I also need is someone to compile Hugin for mac as stand alone application. I asked Max already but he might be far away from his mac recently. Is there anybody else in here that has a Xcode envrionment ready or do I need to get my hands dirty here also ;).,

T.Modes. Are you prividing also mac builds? Would really need to test this fix in the real app.

When I am not taking care of my baby and after som sleep I plan on providing a clean fix for compiling on M1. Will take som time as I need to revisit and dig harder into some of the sources but all in good time.

[Jan Steinman]

Thank you! I'm on an Intec Mac, and still stuck in 2018 or so with Hugin! I'm looking forward to being able to run a more recent release. Wish I had time to help out on it!

[dudek53]

Oki, here´s some conclusions. First. The "fix" in question. In ImageTransformsGPU.cpp I change line 465 to:

const int bytesPerDestPixel = 2 - 2 - 2

It was before:

const int bytesPerDestPixel = 16 + 16 + 8

This allows for functioning corruptfree output even with files with wdth above 6000(pixels?). Big files in other words. THis didn´t work before. I cannot see any speed change by doing this and it can be used also with other intel machines with nvidia cards and so on. WIth that said I don´t see it as a stable fix for all macs. It works on M1 at least.

The gain selecting GPU isn´t all that great but a little speed improvement shows. Around two seconds from 8 to 6 when processing aligning on three images. Tested both intel(nvidia) and Mac M1. Clearly intel is faster with nvidia than rosetta-run processing on M1 so for mac users porting hugin to arm64 probably is a must for the future.

Tests using "time" in bash:

GPU processing

real 0m6.030s
user 0m9.579s
sys 0m2.777s
Daniels-MacBook-Pro:~ daniel$

CPU processing

real 0m7.834s
user 0m34.507s
sys 0m3.147s
Daniels-MacBook-Pro:~ daniel$

Compiling almost fully working. I cannot get make package finalize, probably my paths are missing or wrong so I need to go through this when I have the time to do so.

Otool works good to create portable lib folders so I decided to use this to be able and use align_image_stack on other computers after compiled on my intel machine:

https://github.com/auriamg/macdylibbundler

All in all, good progress even if the fix is a bit random and unscientific.

/D

[T. Modes]

Hi Max

dud...@gmail.com schrieb am Sonntag, 9. April 2023 um 07:58:17 UTC+2:

Oki, here´s some conclusions. First. The "fix" in question. In ImageTransformsGPU.cpp I change line 465 to:

const int bytesPerDestPixel = 2 - 2 - 2

It was before:

const int bytesPerDestPixel = 16 + 16 + 8

This allows for functioning corruptfree output even with files with wdth above 6000(pixels?). Big files in other words. THis didn´t work before. I cannot see any speed change by doing this and it can be used also with other intel machines with nvidia cards and so on. WIth that said I don´t see it as a stable fix for all macs. It works on M1 at least.

First bytesPerDestPixel can now become zero or negative (when using other image formats). This breaks the following calculations or results even in a crash when dividing by zero.

From the first runs it was probably that the corruption occurs when using more than one dest chunk.

So when you decrease bytesPerDestPixel you increase the size of the dest chunk and so nona/align_image_stack is using only one dest chunk and so the corruption does not happen. (run none with --debug switch)

So you workaround the issue in your single usecase but don't the fix the real cause.

Thomas

[dudek53]

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?

By the way. What is the real cause of the issue here?

[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.

[dudek53]

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

[Erkan Özgür Yılmaz]

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

[dudek53]

Cool. I had similar issues, also missing the libboost_atomic.dylib. PackageMacAppBundleLibs.sh gave up after a while as it needs to get a lot of fixes.

Anyway. Would be great if scripts could be updated and shared for M1.

An d I see your build still gives corrupt output from using --gpu with align_image_stack :).

M1 natively (aarch64/arm64)? Are you compiling with aarch64? Could you share your scripts maybe?

[mikko....@kavi.fi]

It’s cool to have a 2022 M1 build, finally. But macOS says the application is damaged, and wont run it.

[dudek53]

Run xattr -cr in terminal on the whole app and it will run.

[Erkan Özgür Yılmaz]

Pushed my changes to my repository:

https://sourceforge.net/u/eoyilmaz/hugin/ci/default/tree/

Because I changed the build scripts so that they are only good for building arm64 I'm not sure if I should create a PR yet. During my research I saw examples of building universal binaries but I didn't bother doing that.

Erkan Ozgur Yilmaz

--

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+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/bf842aab-99a2-4e80-a7d6-86707ca881ecn%40googlegroups.com.

[dudek53]

Nicely done. march=native and correcting paths and such, and I see you did a good job here. Unfortunately I started by reading some mac wiki link suggesting using port for installation but brew seems more stable.

Maybe I´ll dive in again soon to see If I finally will get my M1 doing a full compilation finally :).

To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/CAGNmyx4hAh59gMArYiSaeLnh2Fo-0p6P2SL3WYSubuwTmR7ewA%40mail.gmail.com.

[dudek53]

Hello Erkan. Tested your uploaded hugin source and most of it works out of the box.

The script libglib2.sh in scripts folder tries this in the beginning:

./configure ] && ./autogen.sh

There is no ./autogen.sh in later versions so one could do:

meson _build

Instead accrording to glib2 install notes.

I do configure and then make and all binaries are created but I fail here. I will try adding your libfile to see if this will help but do you see the issue maybe?

/Users/daniel/hugin/mac/ExternalPrograms/repository/include/wx-3.1/wx/osx/app.h:125:26: note: overridden virtual function is here
    virtual void         MacOpenFiles(const wxArrayString &fileNames) ;
                         ^
3 warnings generated.
[ 89%] Building CXX object src/hugin1/ptbatcher/CMakeFiles/PTBatcherGUI.dir/ProgressStatusBar.cpp.o
[ 90%] Building CXX object src/hugin1/ptbatcher/CMakeFiles/PTBatcherGUI.dir/ChangeUserDefinedDialog.cpp.o
/Users/daniel/hugin/src/hugin1/ptbatcher/ChangeUserDefinedDialog.cpp:234:60: error: use of undeclared identifier 'CFSTR'
        wxString thePath = MacGetPathToBundledResourceFile(CFSTR("xrc"));
                                                           ^
/Users/daniel/hugin/src/hugin1/ptbatcher/ChangeUserDefinedDialog.cpp:238:20: error: calling a private constructor of class 'wxString'
            return false;
                   ^
/Users/daniel/hugin/mac/ExternalPrograms/repository/include/wx-3.1/wx/string.h:324:3: note: declared private here
  wxString(int);
  ^
2 errors generated.
make[2]: *** [src/hugin1/ptbatcher/CMakeFiles/PTBatcherGUI.dir/ChangeUserDefinedDialog.cpp.o] Error 1
make[1]: *** [src/hugin1/ptbatcher/CMakeFiles/PTBatcherGUI.dir/all] Error 2
make: *** [all] Error 2
Daniels-MacBook-Pro:build daniel$

[dudek53]

Error seems related to make package bundle which I did not test yet so I guess this needs fixing:

#elif defined __WXMAC__ && defined MAC_SELF_CONTAINED_BUNDLE
    // initialize paths
    {

        wxString thePath = MacGetPathToBundledResourceFile(CFSTR("xrc"));

        if (thePath.IsEmpty())
        {
            wxMessageBox(_("xrc directory not found in bundle"), _("Fatal Error"));
            return false;
        }
        return thePath + "/";
    }

[Erkan Özgür Yılmaz]

Ah yeah sorry I didn’t mention that, I did introduce a couple of changes to the external libraries, I’m not in front of my computer but what I remember is that I changed this line:

/Users/daniel/hugin/src/hugin1/ptbatcher/ChangeUserDefinedDialog.cpp:238:20: error: calling a private constructor of class 'wxString'
            return false;

To return “” instead, and there were other changes in gettext and in glib2 as I remember, will post them in a minute when I got back home.

To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/236fd51f-29e6-41f5-845c-3491be0b4f1fn%40googlegroups.com.

--

Erkan Ozgur Yilmaz

[dudek53]

Nice. Do post. Seems we can soon deliver a solid apple silicon hugin version compiler :).

[Erkan Özgür Yılmaz]

So it seems that I updated libomp and gettext:

libomp

CMake ExtendPath missing

add the following code in CMakeLists.txt

function(extend_path joined_path base_path current_segment)

if("${current_segment}" STREQUAL "")

set(temp_path "${base_path}")

elseif("${base_path}" STREQUAL "")

set(temp_path "${current_segment}")

elseif(IS_ABSOLUTE "${current_segment}")

message(WARNING "Since \"${current_segment}\" is absolute, it overrides base path: \"${base_path}\".")

set(temp_path "${current_segment}")

else()

set(temp_path "${base_path}/${current_segment}")

endif()

set(${joined_path} "${temp_path}" PARENT_SCOPE)

endfunction()

gettext

Replace :

static _Noreturn__ void

print_and_abort (void)

With:

static __attribute_noreturn__ void

print_and_abort (void)

on all the files it exists

[dudek53]

I´ll look into this later today or as soon as possible. i had no issues around gettext though but I´ll test exactly as you descripe.

Could you print the exact fix for this. Tested what you described but if still fails:

Ah yeah sorry I didn’t mention that, I did introduce a couple of changes to the external libraries, I’m not in front of my computer but what I remember is that I changed this line:

/Users/daniel/hugin/src/hugin1/ptbatcher/ChangeUserDefinedDialog.cpp:238:20: error: calling a private constructor of class 'wxString'
            return false;

To return “” instead, and there were other changes in gettext and in glib2 as I remember, will post them in a minute when I got back home.

[Erkan Özgür Yılmaz]

This is the changes I made to ChangeUserDefinedDialog.cpp (apparently I included some header files that should normally be included by the "base_wx/platform.h"):

diff -r 886e4a13e176 src/hugin1/ptbatcher/ChangeUserDefinedDialog.cpp
--- a/src/hugin1/ptbatcher/ChangeUserDefinedDialog.cpp  Sun Apr 09 10:11:55 2023 +0200
+++ b/src/hugin1/ptbatcher/ChangeUserDefinedDialog.cpp  Thu Apr 27 10:43:15 2023 +0100
@@ -24,7 +24,9 @@
  *
  */
 
+#include <CoreFoundation/CoreFoundation.h>
 #include "ChangeUserDefinedDialog.h"
+#include "base_wx/platform.h"
 #include <wx/dir.h>
 #include <wx/stdpaths.h>
 #include <wx/wfstream.h>
@@ -235,7 +237,7 @@

         if (thePath.IsEmpty())
         {
             wxMessageBox(_("xrc directory not found in bundle"), _("Fatal Error"));

-            return false;
+            return "";
         }
         return thePath + "/";
     }

Erkan Ozgur Yilmaz

To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/c3ce4884-a496-468e-a044-35799281718bn%40googlegroups.com.

[dudek53]

Hard stuff for an amaturer coder here ;).

Tried putting in your libomp fix in all CMakeLists.txt in openmp-16.0.1.src but extend path still missing. Would it be too much to ask if you uploaded the whole repo with sources compiled included? I feel I am getting one error after the other here ;).

openmp-13.0.1 seems to work out of the box, maybe use that?

-- LIBOMP: Library Kind         -- SHARED
-- LIBOMP: Library Type         -- normal
-- LIBOMP: Fortran Modules      -- FALSE
-- LIBOMP: Build                -- 20140926
-- LIBOMP: Use Stats-gathering  -- FALSE
-- LIBOMP: Use Debugger-support -- FALSE
-- LIBOMP: Use ITT notify       -- TRUE
-- LIBOMP: Use OMPT-support     -- FALSE
-- LIBOMP: Use OMPD-support     -- FALSE
-- LIBOMP: Use Adaptive locks   -- FALSE
-- LIBOMP: Use quad precision   -- FALSE
-- LIBOMP: Use Hwloc library    -- FALSE
CMake Error at runtime/src/CMakeLists.txt:11 (include):
  include could not find requested file:

    ExtendPath


-- Looking for sqrt in m
-- Looking for sqrt in m - found
-- Looking for __atomic_load_1
-- Looking for __atomic_load_1 - found
-- check-libomp does nothing.
-- check-ompt does nothing.
-- Found Python3: /opt/homebrew/Frameworks/Python.framework/Versions/3.11/bin/python3.11 (found version "3.11.3") found components: Interpreter Development Development.Module Development.Embed
-- check-openmp does nothing.
-- Configuring incomplete, errors occurred!
See also "/Users/daniel/eoyilmaz-hugin/mac/ExternalPrograms/repository/openmp-16.0.1.src/CMakeFiles/CMakeOutput.log".
See also "/Users/daniel/eoyilmaz-hugin/mac/ExternalPrograms/repository/openmp-16.0.1.src/CMakeFiles/CMakeError.log".

** Failed at configure step for arm **
Daniels-MacBook-Pro:~ daniel$

[dudek53]

After your fixes in ChangeUserDefinedDialog.cpp and I skip touching libomp and gettext I am getting all the wway to here. Note that I cannot get glib2 compiling working so I in this case did:
sudo port install libiconv

I guess this could be good or bad in this case. Sorry for the randomness but I rather share wildly at this stage.

* Copying Support Libraries for Hugin.app
* Located in /Users/daniel/build/src/hugin1/hugin
* Installing Library -->/Users/daniel/build/src/celeste/libceleste.0.0.dylib<-- into Hugin.app
* Installing Library -->/Users/daniel/build/src/hugin_base/libhuginbase.0.0.dylib<-- into Hugin.app
* Installing Library -->/Users/daniel/hugin/mac/ExternalPrograms/repository/lib/libGLEW.2.1.dylib<-- into Hugin.app
* Installing Library -->/Users/daniel/hugin/mac/ExternalPrograms/repository/lib/libboost_filesystem.dylib<-- into Hugin.app
* Installing Library -->libboost_atomic.dylib<-- into Hugin.app
cp: libboost_atomic.dylib: No such file or directory
make[2]: *** [Mac] Error 1
make[1]: *** [CMakeFiles/Mac.dir/all] Error 2

make: *** [all] Error 2
Daniels-MacBook-Pro:build daniel$

[dudek53]

I copied atomic lib and some other lib manually to all Libraries when asked and it went all the way here. My libfiles are probably not correct I cannot open Hugin without crash.

I am missing cp: @rpath/libIex-3_1.30.dylib: No such file or directory

I guess my renaming another liblex file to the missing oen is not gonna work. But I wanted to see how far this would go.

*-----------------------------------------------------------*
* Copying Support Libraries for HuginStitchProject.app
* Located in /Users/daniel/build/src/hugin1/stitch_project
[ 90%] Built target Mac
[100%] Built target ManPages
Run CPack packaging tool...
CPack: Create package using DragNDrop
CPack: Install projects
CPack: - Run preinstall target for: hugin
CPack: - Install project: hugin []
CPack: -   Install component: tools_mac
CPack: -   Install component: Hugin
CPack: -   Install component: PTBatcherGUI
CPack: -   Install component: calibrate_lens_gui
CPack: -   Install component: HuginStitchProject
CPack: Create package
CPack Error: Error executing: osascript "/Users/daniel/hugin/mac/DmgScript.scpt" "Hugin-2022.1.0"
CPack Error: Error executing custom script on disk image.
/Users/daniel/hugin/mac/DmgScript.scpt: execution error: Finder got an error: Can’t set item "Hugin-2022.1.0" of Finder window id 23744 to {108, 135}. (-10006)

CPack Error: Problem compressing the directory
CPack Error: Error when generating package: Hugin
make: *** [package] Error 1
Daniels-MacBook-Pro:build daniel$

You received this message because you are subscribed to a topic in the Google Groups "hugin and other free panoramic software" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/hugin-ptx/cAzcl7HaQs4/unsubscribe.
To unsubscribe from this group and all its topics, send an email to hugin-ptx+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/90f63dea-ec61-4b93-b32c-62dccb45642fn%40googlegroups.com.

[Erkan Özgür Yılmaz]

You probably have OpenEXR 3.1 installed somewhere with homebrew or Macports, I reckon you need to remove that from your system, or update your link commands "-L" not to include any folders that contain libIex*.dylib. Normally hugin's build scripts are downloading/building OpenEXR 2.5.x.

Erkan Ozgur Yilmaz

To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/CAHk3tqjb4hUQr%2B1Mhym3GT6rJHAns7KRxsXL1C-hMOwv99TUJg%40mail.gmail.com.

[dudek53]

A, probably!  Will check again tonight.

Openexr, libiconv, gsl2 has been bugging for a looong time 😎. All binaries compiled but make install and make package still breaks. 

To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/CAGNmyx4s1PG82NFfvy%2BkXBijBHp24HGjZ9oByxwf3UFOsSkgEg%40mail.gmail.com.

[Gunter Königsmann]

One message of this thread mentioned C++ complains about using a private method of wxString. That error message normally means that a function expects totally different types of arguments than it gets from the current code.

If you allow the system to automatically convert everything to wxString and wxString to everything else without that causing an error you can call all versions of all functions with all types of arguments in any order without causing any error any more. But calling that function with those arguments still won't make any sense.p

[dudek53]

Hugin arm64 build here(Standalone):

https://bitbucket.org/Dannephoto/hugin/downloads/Hugin-2022.1.0_arm64.dmg

Please test and report if it works or not(Mac M1 or M2 arm64)

Make sure to run this in terminal before starting the app:

xattr -cr /Applications/Hugin

Hit enter

Some progress around building a standalone arm64 package. Following Erkans changes and also adding a change in boost.sh script tha last libs for hugin to become fully stand alone is handled at the bottom of boost.sh. atomic lib had no prefixed path and libboost_system.dylib cried about where atomic lib were to be found. All fixed now.

if [ -f "$REPOSITORYDIR/lib/libboost_atomic.dylib" ]; then
 install_name_tool -id "$REPOSITORYDIR/lib/libboost_atomic.dylib" "$REPOSITORYDIR/lib/libboost_atomic.dylib";
 install_name_tool -change "libboost_atomic.dylib" "$REPOSITORYDIR/lib/libboost_atomic.dylib" "$REPOSITORYDIR/lib/libboost_atomic.dylib";
fi

if [ -f "$REPOSITORYDIR/lib/libboost_filesystem.dylib" ]; then
 install_name_tool -id "$REPOSITORYDIR/lib/libboost_filesystem.dylib" "$REPOSITORYDIR/lib/libboost_filesystem.dylib";
 install_name_tool -change "libboost_system.dylib" "$REPOSITORYDIR/lib/libboost_system.dylib" "$REPOSITORYDIR/lib/libboost_filesystem.dylib";
 install_name_tool -change "libboost_atomic.dylib" "$REPOSITORYDIR/lib/libboost_atomic.dylib" "$REPOSITORYDIR/lib/libboost_filesystem.dylib"
fi

if [ -f "$REPOSITORYDIR/lib/libboost_system.dylib" ]; then
 install_name_tool -id "$REPOSITORYDIR/lib/libboost_system.dylib" "$REPOSITORYDIR/lib/libboost_system.dylib";
fi

if [ -f "$REPOSITORYDIR/lib/libboost_atomic.dylib" ]; then
 install_name_tool -id "$REPOSITORYDIR/lib/libboost_atomic.dylib" "$REPOSITORYDIR/lib/libboost_atomic.dylib";
fi

[dudek53]

Added sources and diffed the arm64 hugin source against latest official sources here. Maybe helps to follow changes from Erkan and me:
https://bitbucket.org/Dannephoto/hugin/src/master/

[T. Modes]

dud...@gmail.com schrieb am Freitag, 5. Mai 2023 um 11:38:20 UTC+2:

Added sources and diffed the arm64 hugin source against latest official sources here. Maybe helps to follow changes from Erkan and me:
https://bitbucket.org/Dannephoto/hugin/src/master/

sorry, but it does not help. This is hacking that it works for *you* only and not for any other.

Instead of cloning the existing repository you copied all files to a new git repo. Now the whole history is lost. Also it is unknown on which changeset it is based.

Next, in one changeset you copied the files from the official hugin repo. In the next changeset you add your changes and at the same time you revert a lot of changes to an earlier changeset of the Hugin repo- which is also unknown.

So the changeset is more complicated than necessary. It contains your changes and a lot of unrelated and unnecessary changes at the same time. This makes it very confusing to see your changes only.

Hugins build system is connected with the mercurial repo. By switching to git you break this and need to add a file which is (intentional) not under revision control in mercurial. (There are special ways to handle the releases, but these should not be used in development in between.)

Next your changes in the source code break the compilation on all other platforms -> "works for me" is not enough. The changes must not break compilation (and running) on other systems.

Also randomly changing numbers and sign in the source code without understanding what you do only that it works in *your* single use case is not acceptable. I mentioned this already to you but you have ignored this.

Also changing lines in the script and then commenting out the same line is a bad style and makes the diff more confuse than needed.

Beside all these mentioned issue it would be recommend to split the changes into small chunks: e.g. one changeset with only changes to the build script, a second one with the needed code changes.

Combined it is very difficult to review your changes because of all these mentioned points.

Currently it can't applied to official repo because it breaks existing code.

[dudek53]

Hi. Hacking? Not really following what you mean. Heavy on the negativity here.

I´ll remove the sources for now. They were published for users or others to build upon. I have a hard time seeing a better way at this stage documenting this but others are free to chime in. I keep my personal stuff secluded from now on.

This work is mainly done from Erkan so I assume what he posted is as unorthodox. Hopefully he´ll fullfill his work when he can according to the "rules" and guidelines.

If anyone wants to play with my changes they can contact me and i´ll help or share findings in that case.

Have a great weekend all.

 /D

[dudek53]

Regarding the numbers that fixed my issue. Could you suggest a way to verify the validity of the fix? I tested it on 5-6 different workstations with different people having the same issue and the fix fully worked on all stations. I sincerely would like to get the fix reviewed from the code author or someone with knowledge in this are but I would need some help here to find out the right person to ask.

Meanwhile. Any usage around this build that has been shared comes with no warranty. Use with sense.

[T. Modes]

dud...@gmail.com schrieb am Freitag, 5. Mai 2023 um 17:40:17 UTC+2:

Regarding the numbers that fixed my issue. Could you suggest a way to verify the validity of the fix? I tested it on 5-6 different workstations with different people having the same issue and the fix fully worked on all stations.

I thought I explained it already in my earlier replies.

Just 2 tests cases after applying your changes:

* Input gray scale images: works in official version, crashes with your numbers

* Large output image (e.g. 34000x27000): works in official version, with your numbers it stops with an error message

I think there could be more cases…

 

[dudek53]

Oki, oki, I must have missed this info. Thanks for pointing out. Actually. My hack fix wasn´t meant to be included in my M1 build. Forgot to remove it.

I will make further investigating here on my own. Gray scale images, regardless of size? Also will check with humoungous files.

I am very interested in learning the stuff and finally being able to compile feels really nice. I often work openly sharing work in progress as I see it as an important first step to hunt down severe bugs or other anomalies. NExt step, cleaning up and pushing safe commits comes later. Maybe I should find an experimental group in here.

Anyway. Thanks for pointing me in directions.

/D

[dgjohnston]

After having to create an Atlassian account to login and access bitbucket, I get the error message "You do not have access to this repository.”

Is there a less intrusive way to access this download?

Don J.

--
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+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/CAHk3tqi%3DXdZ%2Be3FffqynwMiixrhDp5hkqVpQnNvkQVkypRHwbQ%40mail.gmail.com.

[Gunter Königsmann]

I still get a "repository not found" error.

[Erkan Özgür Yılmaz]

yeah me too...

Erkan Ozgur Yilmaz

On Sat, 6 May 2023 at 10:09, Gunter Königsmann <gunter.ko...@gmail.com> wrote:

I still get a "repository not found" error.

--

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+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/A91864FB-A2C5-44ED-8C96-2BF2D791F885%40gmail.com.

[dudek53]

Sorry guys. Getting issues. Needs fixing first.

[Luís Henrique Camargo Quiroz]

   Hi,

   Just to say that for beginners it may seem confusing how to use git or mercurial, start a new branch, etc. I think that anything done so far was in the best intention to help, especially for those with Macs.

   I don't think that Tomas meant to be heavy on negativity, nor with intent of discouraging anyone, but an alert to be double cautious, because of the problems we can create in git/mercurial/others -- I myself have never found a concise and perfectly understandable guide on how to use these programs. And while adventuring to fix software from others made many mistakes too, because there were lots of things I was ignorant about. I ever had to spend time, months maybe, until I knew what was the right thing to do.

   nice weekend!

   Luís Henrique

--
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+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/e23c72ba-9242-4622-acde-163c72bc8839n%40googlegroups.com.

--

--
Luis Henrique Camargo Quiroz
http://luishcq.br.tripod.com - http://www.christusrex.org/www2/cantgreg
http://panoramaslh.net/

[dudek53]

All good if you ask me 👍.

To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/CAEKSoZbcrTL%3DnoHkR0XqRQgBY_-Ys1EUhg0cpYhRFGg_SFrv4A%40mail.gmail.com.

[dudek53]

Having issue again, go figure :).

Compiling fine but getting segmentations faults and also something called Bus error 10 when running align_image_stack,

Opening up hugin I am getting this error code. Just putting it out there for checking. I am building upon Erkans changes. His versions works just fine, mine do not :).

<?xml version="1.0" encoding="UTF-8"?>
<report version="1.0" kind="exception">
  <system description="macOS Version 13.3.1 (Build 22E261)"/>
  <stack>
    <frame level="0" function="wxFatalSignalHandler(int)" offset="0" address="0x10231b2b0"/>
    <frame level="1" function="_sigtramp" offset="0" address="0x183646a84"/>
    <frame level="2" function="vigra::JPEGDecoderImpl::JPEGDecoderImpl(std::__1::basic_string&lt;char, std::__1::char_traits&lt;char&gt;, std::__1::allocator&lt;char&gt;&gt; const&amp;)" offset="0" address="0x1008f9884"/>
    <frame level="3" function="vigra::JPEGDecoderImpl::JPEGDecoderImpl(std::__1::basic_string&lt;char, std::__1::char_traits&lt;char&gt;, std::__1::allocator&lt;char&gt;&gt; const&amp;)" offset="0" address="0x1008f9884"/>
    <frame level="4" function="vigra::JPEGDecoder::init(std::__1::basic_string&lt;char, std::__1::char_traits&lt;char&gt;, std::__1::allocator&lt;char&gt;&gt; const&amp;)" offset="0" address="0x1008f9cb8"/>
    <frame level="5" function="vigra::CodecManager::getDecoder(std::__1::basic_string&lt;char, std::__1::char_traits&lt;char&gt;, std::__1::allocator&lt;char&gt;&gt; const&amp;, std::__1::basic_string&lt;char, std::__1::char_traits&lt;char&gt;, std::__1::allocator&lt;char&gt;&gt; const&amp;, unsigned int) const" offset="0" address="0x1008e4200"/>
    <frame level="6" function="vigra::ImageImportInfo::readHeader_()" offset="0" address="0x1008f3cdc"/>
    <frame level="7" function="vigra::ImageImportInfo::ImageImportInfo(char const*, unsigned int)" offset="0" address="0x1008f3bfc"/>
    <frame level="8" function="PanoCommand::wxAddImagesCmd::processPanorama(HuginBase::Panorama&amp;)" offset="0" address="0x101187bd4"/>
    <frame level="9" function="PanoCommand::CombinedPanoCommand::processPanorama(HuginBase::Panorama&amp;)" offset="0" address="0x10117ca7c"/>
    <frame level="10" function="PanoCommand::PanoCommand::execute()" offset="0" address="0x10117c710"/>
    <frame level="11" function="PanoCommand::CommandHistory::addCommand(PanoCommand::PanoCommand*, bool)" offset="0" address="0x10119fb08"/>
    <frame level="12" function="PanoDropTarget::OnDropFiles(int, int, wxArrayString const&amp;)" offset="0" address="0x1003f58bc"/>
    <frame level="13" function="wxFileDropTarget::OnData(int, int, wxDragResult)" offset="0" address="0x10247a638"/>
    <frame level="14" function="wxWidgetCocoaImpl::performDragOperation(void*, NSView*, void*)" offset="0" address="0x10241bde4"/>
    <frame level="15" function="wxOSX_performDragOperation(objc_object*, objc_selector*, id&lt;NSDraggingInfo&gt;)" offset="0" address="0x10241ad4c"/>
    <frame level="16" function="NSCoreDragReceiveMessageProc" offset="0" address="0x186ba6aa0"/>
    <frame level="17" function="CallReceiveMessageCollectionWithMessage" offset="0" address="0x188e73c14"/>
    <frame level="18" function="DoMultipartDropMessage" offset="0" address="0x188e6dc94"/>
    <frame level="19" function="DoDropMessage" offset="0" address="0x188e6da4c"/>
    <frame level="20" function="CoreDragMessageHandler" offset="0" address="0x188e717ec"/>
    <frame level="21" function="__CFMessagePortPerform" offset="0" address="0x18379af24"/>
    <frame level="22" function="__CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE1_PERFORM_FUNCTION__" offset="0" address="0x1836f6ca0"/>
    <frame level="23" function="__CFRunLoopDoSource1" offset="0" address="0x1836f6bc0"/>
    <frame level="24" function="__CFRunLoopRun" offset="0" address="0x1836f55a0"/>
    <frame level="25" function="CFRunLoopRunSpecific" offset="0" address="0x1836f458c"/>
    <frame level="26" function="RunCurrentEventLoopInMode" offset="0" address="0x18cf29df4"/>
    <frame level="27" function="ReceiveNextEventCommon" offset="0" address="0x18cf29c30"/>
    <frame level="28" function="_BlockUntilNextEventMatchingListInModeWithFilter" offset="0" address="0x18cf29988"/>
    <frame level="29" function="_DPSNextEvent" offset="0" address="0x186913f58"/>
    <frame level="30" function="-[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:]" offset="0" address="0x1869130f4"/>
    <frame level="31" function="-[NSApplication run]" offset="0" address="0x186907558"/>
    <frame level="32" function="wxGUIEventLoop::OSXDoRun()" offset="0" address="0x1023ed6ec"/>
    <frame level="33" function="wxCFEventLoop::DoRun()" offset="0" address="0x102307450"/>
    <frame level="34" function="wxEventLoopBase::Run()" offset="0" address="0x1022741c4"/>
    <frame level="35" function="wxAppConsoleBase::MainLoop()" offset="0" address="0x10224e450"/>
    <frame level="36" function="wxApp::OnRun()" offset="0" address="0x10238b494"/>
    <frame level="37" function="wxEntry(int&amp;, wchar_t**)" offset="0" address="0x1022a0018"/>
    <frame level="38" function="main" offset="0" address="0x1003ed2ac"/>
    <frame level="39" function="start" offset="0" address="0x1832bff28"/>
  </stack>
</report>

[dudek53]

Turns out Vigra was not healthy working anymore. Cannot make it work so disabled it and used sudo port install vigra instead which works. Seems I have it working and standalone for arm64 atm but will do more tests.

[dudek53]

I am back.

Testers for arm264 Hugin version(M1,M2):

https://bitbucket.org/Dannephoto/hugin/downloads/Hugin-2023-05-03_arm64.dmg

After install do following in terminal:

xattr -cr drag/hugin/folder/here then push enter

After this it should open fine.

Hugin is compiled including the latest official code from may 5th 2023.

Official commit:

https://sourceforge.net/p/hugin/hugin/ci/fe8370d506bbcebac0aedc4c7638e05990949d86/

Full compile source

https://bitbucket.org/Dannephoto/hugin/downloads/hugin-2023-05-03_arm64.zip

I have no intention to stick with bitbucket git repo. Down the pipe I am thinking it will be pushed in mercurial default repo. As for now, it is a work in progress.

Changes are all happening in mac folder. Nothing has been changed in source files. My --gpu hack fix is not included in this build.

Bitbucket commit:

https://bitbucket.org/Dannephoto/hugin/commits/9c0df86f0557514fdca900cf690d43d58ae2eff1

To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/9fe7c5b5-12db-459b-87f2-ce5833f67b4fn%40googlegroups.com.

[dgjohnston]

Hi, I’ve started some testing for hugin on my M1 MacBook Pro running macOS Ventura 13.3.1.

The following two images show the difference I see in the “Fast Panorama preview” screen. It looks like something isn’t displaying the sections properly.

If you look closely, the text in the big 1, 2, 3 boxes is barely readable “Load images”, “Align”, “Create"

Let me know if you need any other details.

[dudek53]

Hi Donald. Thanks for sharing. I see the same view on my computer. Are functions working ok otherwise? If you could do some more tests and sum up your experiences I could then have a look and see if I could fix this. Other than graphical issues it is interesting to see the app works faster using arm64 compiler. My tests around align_image_stack and enfuse shows a significant speed increase.

[dgjohnston]

I’ve done some testing on older .pto files I have. They seem to be running similar to the previous versions of hugin.

One of the largest .pto files I have took 39 seconds to stitch on hugin 2022 on my Mac and only 28 sec using your compiled hugin 2023 (about a 30% reduction).

I’ll try some testing by redoing the larger set of images that I have and see if the interface is usable with the problem I highlighted in my last email.

Thanks for the work you’ve done on compiling this for the M1.

Don J.

--
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+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/90cfc9d1-9218-40c9-8629-b78d639420d5n%40googlegroups.com.

[dudek53]

Amazing. And glad to hear about speed increase. 30% are about exactly what to be expected here so we are in right track here. I get approximately the same with enfuse and align_image_stack but from within adobe lightroom.

I´ll have a look on the graphical glitch when I can. Maybe it can be solved with some older wxWidgets source idk really but I could try at least :).

Thanks for sharing yoiur findings!

/D

[dgjohnston]

Dudek53 … additional testing of various size PTO file I have is showing a time reduction of 28% to 30% with your load of hugin for M1.

Will you be doing some additional testing on the graphic interface for hugin that I sent previously?

Don J.

On May 18, 2023, at 11:42 AM, dudek53 <dud...@gmail.com> wrote:

--
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+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/90cfc9d1-9218-40c9-8629-b78d639420d5n%40googlegroups.com.

[dudek53]

Hi again! Na again it is nice to see the speed increase.

I had a look a while ago but couldn´t find any issue here. Makes me wonder if the graphical change is suppose to be like this. Maybe T. Modes or some one else could verify this? I was thinking of climbing back in source tree and see where the change happens in code but didn´t have time yet and it would probably introduce some compiler bugs again.

To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/77C8A07D-8ABD-42FE-95AA-94B445D6E297%40accesscomm.ca.

[dudek53]

Hi again! And again it is nice to see the speed increase.

I had a look a while ago but couldn´t find any issue here. Makes me wonder if the graphical change is suppose to be like this. Maybe T. Modes or some one else could verify this? I was thinking of climbing back in source tree and see where the change happens in code but didn´t have time yet and it would probably introduce some compiler bugs again.

On Wed, May 31, 2023 at 12:52 AM dgjohnston <dgjoh...@accesscomm.ca> wrote:

To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/77C8A07D-8ABD-42FE-95AA-94B445D6E297%40accesscomm.ca.

[T. Modes]

dud...@gmail.com schrieb am Mittwoch, 31. Mai 2023 um 05:27:02 UTC+2:

I had a look a while ago but couldn´t find any issue here. Makes me wonder if the graphical change is suppose to be like this. Maybe T. Modes or some one else could verify this? 

It works fine on Windows and Linux, I don't see problems here.

There was an attached image mentioned, which should show the issue. But there is no image attached. So I don't know what you mean. It seems to be a Mac issue which only "insiders" knows and nobody else.

So a screenshot with the issue and some more information would be needed, e.g. wxWidgets version, is this a HiDPI display?, (if so scaling factor)

I can't read thoughts…

Thomas

[dudek53]

Well I've seen the image. Maybe taken down. Maybe the author could repost it if that's the case. 

Regards

/The Mac club

--

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+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/bcc65cdb-51dc-44a3-b0d7-1f8073f0d14bn%40googlegroups.com.

[T. Modes]

dud...@gmail.com schrieb am Mittwoch, 31. Mai 2023 um 18:05:25 UTC+2:

Well I've seen the image. Maybe taken down.

There is no attached image in the web interface.

Maybe the author could repost it if that's the case. 

Interesting. You can reproduce the glitch but are not able to provide a screenshot on your own?

There are also some questions which the builder should able to answer (e.g. wxWidgets version). These are still unanswered.

[dudek53]

I can provide it all later tonight. I am working but yes, I have time to answer like this. I could stop answering if that feels better 

Why the hostility? I am here to help and to receive help :).

Hugin rocks 👌❤️. Very happy that it seems to work for apple Silicon finally 👌

--
A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ
---

You received this message because you are subscribed to a topic in the Google Groups "hugin and other free panoramic software" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/hugin-ptx/cAzcl7HaQs4/unsubscribe.
To unsubscribe from this group and all its topics, send an email to hugin-ptx+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/63cf19c1-750b-40b8-a0ff-1fe0eb3b3175n%40googlegroups.com.

[dgjohnston]

Thanks dude53! I certainly appreciated the work you’ve put into getting this going for Mac silicon!

And Thomas any help you can provide is also appreciated. Here are the two images that I’d posted earlier.

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+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/CAHk3tqjYSpb6PQxcKD3Hs3DL8HuAqfNh1%2B4irP1YgK%3DHNTWf9A%40mail.gmail.com.

[dudek53]

Thanks. Appreciate it. Today I also added T. Modes latest changes:

https://bitbucket.org/Dannephoto/hugin/downloads/Hugin-2023.05.24.arm64.dmg

I feel a bit ashamed keeping it at git atm but I will get it up on HG eventually. But better than nothing.

I compiled with following sources:
https://i.postimg.cc/1RpvG568/Screenshot-2023-05-31-at-18-33-55.png

Also tried changing to an older version of wxWidgets but since I suspect it is nothing wrong but maybe a code change not included in 2019 version I would like to verify if a bug or not.

Regards

/Daniel

To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/DC249C11-5806-4163-9F2E-38313228DF03%40accesscomm.ca.

[T. Modes]

Hi Donald,

Donald Johnston schrieb am Mittwoch, 31. Mai 2023 um 18:30:40 UTC+2:

And Thomas any help you can provide is also appreciated. Here are the two images that I’d posted earlier.

thanks for the feedback. But these images don't appear in the web interface. Other attachment appear also in the mailing list. Not sure what the problem here is with these images.

Thomas

[dudek53]

I see the files just fine from Donald.

These are the differences:

2023

https://i.postimg.cc/0562Nj6J/Screenshot-2023-05-31-at-18-31-26.png

2019

https://i.postimg.cc/z3mQz0yp/Screenshot-2023-05-31-at-18-54-32.png

--
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+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/962ebb4c-f0c7-451f-b8dd-e8a656d7478dn%40googlegroups.com.

[T. Modes]

Donald Johnston schrieb am Mittwoch, 31. Mai 2023 um 18:30:40 UTC+2:

Thanks dude53! I certainly appreciated the work you’ve put into getting this going for Mac silicon!

And Thomas any help you can provide is also appreciated. Here are the two images that I’d posted earlier.

Okay, we make progress.

Does this happen only in dark mode? When disabling dark mode does looks it better?

[dudek53]

Hehe, You are perfectly correct on the dark mode vas daylight. Here is when dark mode is turned off:

https://i.postimg.cc/brmt1HSP/Screenshot-2023-05-31-at-19-45-44.png

--
A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ
---
You received this message because you are subscribed to a topic in the Google Groups "hugin and other free panoramic software" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/hugin-ptx/cAzcl7HaQs4/unsubscribe.
To unsubscribe from this group and all its topics, send an email to hugin-ptx+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/c6f0432a-6ced-47a1-8038-e9409aa477b8n%40googlegroups.com.

[dgjohnston]

Yes, same here. Under “Appearance” in the Mac System settings I changed between Light and Dark and the text is readable.

Now it’s just the big ugly 1, 2, and 3 … (smilie face) … seriously that’s not an issue.

What’s missing also is the “lens type” and “Focal length” etc. between the 1 and 2 buttons. The drop down is connected to the “Load Images” button so it is not obvious.

Don J.

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+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/CAHk3tqinO1bGXfmNB3wqC279DYxPaOS4tXORZg3oKQvyyZQuyA%40mail.gmail.com.

[T. Modes]

Donald Johnston schrieb am Mittwoch, 31. Mai 2023 um 21:37:36 UTC+2:

Yes, same here. Under “Appearance” in the Mac System settings I changed between Light and Dark and the text is readable.

Now it’s just the big ugly 1, 2, and 3 … (smilie face) … seriously that’s not an issue.

What’s missing also is the “lens type” and “Focal length” etc. between the 1 and 2 buttons. The drop down is connected to the “Load Images” button so it is not obvious.

No, it is not missing. The tab was simplified in version 2022.0 and unneeded functions for the assistant tab were removed. This is mentioned in the release notes.

There were some discussion about it some time ago: https://groups.google.com/g/hugin-ptx/c/Vzd1vq2eY9Y

Concerning the dark mode: here we are using directly the functions from wxWidgets to draw the button. Maybe this was fixed in a later version. There were some issues related to dark mode mentioned in the changelog/release notes.

[T. Modes]

Attached is a patch which should try to set the background color to the correct color.

Please test if this fixes the issue in dark mode and if it works also in non-dark mode.

Thomas

[dudek53]

Dusting off my hg knowledge applied the patch

hg import splitbutton_bgcolor.diff

Patch applied, checked context:

bool SplitButton::Create(wxWindow* parent, wxWindowID id, const wxString& label, const wxPoint& pos, const wxSize& size, const wxString& name)
{
    if (!wxPanel::Create(parent, id, pos, size, wxBORDER_NONE | wxTAB_TRAVERSAL))
    {
        return false;
    }
    m_label = label;

    if (size == wxDefaultSize)
    {
        UpdateMinSize();
    }
#ifdef __WXMAC__
    // explicitly set background color for Mac
    // otherwise DrawPushButton does not draw button correctly when dark mode is enabled
    SetBackgroundColour(wxSystemSettings::GetColour(wxSYS_COLOUR_BTNFACE));
#endif

    Bind(wxEVT_PAINT, &SplitButton::OnPaint, this);
    Bind(wxEVT_LEFT_UP, &SplitButton::OnLeftButtonUp, this);
    Bind(wxEVT_LEFT_DOWN, &SplitButton::OnLeftButtonDown, this);
    Bind(wxEVT_KILL_FOCUS, &SplitButton::OnKillFocus, this);
    Bind(wxEVT_LEAVE_WINDOW, &SplitButton::OnMouseLeave, this);
    Bind(wxEVT_ENTER_WINDOW, &SplitButton::OnMouseEnter, this);

    m_dropDownMenu = new wxMenu();
    return true;
}

Unfortunately behaviour is still the same. In dark mode:

https://i.postimg.cc/9fnKLnWr/Screenshot-2023-06-01-at-19-59-52.png

Light mode works as expected the same as before.

--

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+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/3d19b13a-6417-4055-9b08-146b08aafb17n%40googlegroups.com.

[dudek53]

Another question regarding --gpu setting in align_image_stack. I notice that every time gpu processing initiates when aligning the binary takes over the frontmost window. It is very short but when batch processing stacks for instance every stack will have a moment of interrupting other windows on mac. The binary sort of opens up in bottom bar:
https://i.postimg.cc/0QKd4pxJ/Screenshot-2023-06-02-at-11-01-51.png

Example command line:

align_image_stack -a outputfiles --gpu inputfile1.tiff intpufile2.tiff inputfile3.tiff

So far I tried checking utils.cpp to see where this comes from. I am looking at bool initGPU(int *argcp, char **argv) I suspect maybe this routine is needed and can´t be run silently? If not I am wondering if a -q (quiet) mode is possible?

[dudek53]

Answering myself on this one. Commenting out following in utils.cpp stops align_image_stack from opening and closing on every process when --gpu is enabled

//glutInit(argcp, argv);

Did a few tests, output was working and gpu processing did what it was suppose to do. Consider it a blind testfix for my particular usage area as I don´t know if it breaks other processes in the program. Anyway,. Only documenting this stuff. Not claiming I solved any issues for anybody else than me and my mac friends ;).

Good evening.

/D

[Gunter Königsmann]

Not initializing glut before using it sounds scary...

[dudek53]

How do you mean? Could you show me a way to break processing while doing it?

[dudek53]

Might have a fix for the button issue when in darkmode. Feel free to refine it.
https://i.postimg.cc/FKfBRYxH/Screenshot-2023-06-15-at-19-27-12.png

Download:
https://bitbucket.org/Dannephoto/hugin/downloads/Hugin-2023-05-03_arm64.dmg

In splitbutton.cpp:

void SplitButton::OnPaint(wxPaintEvent& WXUNUSED(event))
{
    wxPaintDC dc(this);
    wxSize size = GetSize();
    const int width = size.GetWidth() - m_arrowButtonWidth;

    // Draw first part of button
    wxRect r1;
    r1.x = 0;
    r1.y = 0;
    r1.width = width + 2;
    r1.height = size.GetHeight();

    wxRendererNative::Get().DrawPushButton(this, dc, r1, m_stateButton);

    // Determine text color based on dark mode
    wxColour textColor;
#ifdef __WXMAC__
    bool darkModeEnabled = wxSystemSettings::GetAppearance().IsDark();
    if (darkModeEnabled)
        textColor = m_IsEnabled ? wxColour(0, 0, 0) : wxColour(192, 192, 192); // Black color for dark mode, if not enabled use gray
    else
        textColor = wxSystemSettings::GetColour(m_IsEnabled ? wxSYS_COLOUR_BTNTEXT : wxSYS_COLOUR_GRAYTEXT);
#else
    textColor = wxSystemSettings::GetColour(m_IsEnabled ? wxSYS_COLOUR_BTNTEXT : wxSYS_COLOUR_GRAYTEXT);
#endif

    dc.SetTextForeground(textColor);

    // draw label and bitmap
    if (HasBitmap())
    {
        dc.DrawLabel(m_label, m_bitmap, r1, wxALIGN_CENTER);
    }
    else
    {
        dc.DrawLabel(m_label, r1, wxALIGN_CENTER);
    };

    // Draw second part of button
    wxRect r2;
    r2.x = width - 2;
    r2.y = 0;
    r2.width = m_arrowButtonWidth;
    r2.height = size.GetHeight();

    wxRendererNative::Get().DrawPushButton(this, dc, r2, m_stateMenu);
    wxRendererNative::Get().DrawDropArrow(this, dc, r2, m_stateMenu);
}

git commit only for diff view purposes:

https://bitbucket.org/Dannephoto/hugin/commits/6cdffbb463c015adedf8e4a4c1fec9f910571ba4

[T. Modes]

dud...@gmail.com schrieb am Donnerstag, 15. Juni 2023 um 20:34:54 UTC+2:

Might have a fix for the button issue when in darkmode. Feel free to refine it.

In splitbutton.cpp:

void SplitButton::OnPaint(wxPaintEvent& WXUNUSED(event))

Please don't copy the full code into the mail. First the software/mail client can reformat the code lines - this can introduce a lot of unnecessary trouble.

Second it is not so obviously what you changed exactly.

Please attached instead a unified diff (from hg diff). This makes the handling of such changes more easily.

The changes affect only the caption (text) of the button, but not the drawing of the buttons itself. These are still wrongly drawn.

Second, I don't like the fixed coded colours. What if the users theme is using other colours? Then it looks wrong again.

[dudek53]

Any suggestions and refinements are most welcome. Still the better starting point than what we had before.

I hope I get some time to tinker next week 👍.

Have a nice evening.

/D

--
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+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/3ae298e7-1f3a-429a-b395-3d6e2ea1abb3n%40googlegroups.com.

[Luca Zulberti]

Hi all,

I'm trying to use Hugin 2022.1.0 on MacOS 13.5.

I downloaded the patched code from: https://bitbucket.org/Dannephoto/hugin

I modified DEPLOY_TARGET to 13.5 in configure and SetEnv scripts.

I run downlaod_all and build_all scripts successfully.

I run configure-bundle script from build directory successfully.

I generated successfully the dmg image (make -j package)

When I launch Hugin, it crashes:

https://docs.google.com/document/d/e/2PACX-1vRuIUw9Ix4eewPi-mXRwcC_mButLybnSSDarWoPE8uFNIlhc42UPds00LsPc1u1WWgyMrS5NMApqtaM/pub

Would you happen to have any hints for me?

Thank you for your effort.

Luca

[dudek53]

Releasing a mac arm64 build according to this source code relaease from T.Modes:
https://groups.google.com/g/hugin-ptx/c/t_S1YAgfTf8/m/TgoQq0cxIgAJ

Hugin-2023.0.0_beta_1_arm64.dmg

Briefly tested and working.

Please test and report bug/issues to mailing list or bug tracker https://bugs.launchpad.net/hugin (so issues can be fixed before the final release).

[T. Modes]

Thanks for building, but …

dud...@gmail.com schrieb am Samstag, 23. September 2023 um 10:08:41 UTC+2:

Releasing a mac arm64 build according to this source code relaease from T.Modes:

Please use the dedicated thread for the beta 1 release for such announcement and not your "private" mac thread.

So all reports concerning the beta 1 are in one thread and not scattered about several ones.

This was explicitly written in the announcement.