Can't make Hugin stitch my photos.

[Buddy Moran]

I'm trying to stitch photos manually taken from a DJI Phantom 3 Pro into a 360 panorama (not any drone panorama app). I'm running Hugin on a MacBook Pro running on macOS Sierra v10.12.2. But I could not get Hugin (which I am very new to) to stitch. I wanted to stitch after post processing the photos with Lightroom. I wanted to test whether Hugin would work, though. So I did a trial with the JPG files, first. After loading, aligning and move/dragging, a preview showed that a stitched panoramic image (Screen Shot attached). But when I tried to stitch, I just received a "Failed" status and a "Batch completed with errors" message at the bottom of the Batch Processor window.

I'd really appreciate someone pointing out what I may have been doing wrong. I'm also attaching the Hugin project file and the log file. This link to Dropbox contains the JPG photos: https://www.dropbox.com/sh/04lvkc21wmh3vna/AADjbPb5Spw1IszXPbdYAm5Ca?dl=0

Regards,

Buddy 

[Marius Loots]

Hallo Buddy,

Was able to stitch your images without problem. For the result, see:
https://www.dropbox.com/sh/hnst5v1pruchv28/AADV2_pNoIOWmMpzsIHQdYYua?dl=0

I created my own project file, as well as using yours. There is slight
differences in the result. I uploaded my project file as well.

There are some images that completely overlap areas that are already
covered. To see this, open the Fast Preview Interface, as per your
screen shot.

For displayed images, click None.
Now, starting from the left at 0, add images to the display by
clicking on the boxes 0 to 36. After the first nine images, a complete
upper row of the panorama is filled in. 10 evens out the top and
bottom edge of this row, 11 adds an imperceptible edge at the bottom
of image 9/0/1.

If I remember correctly, this used to be a problem in some versions of
hugin or its supporting modules. In the log file, refer to:
enblend: warning: some images are redundant and will not be blended
enblend: note: usually this means that at least one of the images
enblend: note: does not belong to the set

I suggest
1 Looking at a different version or different build.
2 Removing the redundant images. I can't advise to exactly which
versions, as I am on windows and not MacOS.

1 is the better option if you plan to do more of these. It becomes a
pain to hunt the overlaps.
2 is easier if you just want to get the job done now.

Nice view, share the final result.

Groetnis
Marius

--
add some chaos to your life and put the world in order
http://www.mapungubwe.co.za/
http://www.chaos.co.za/
skype: marius_loots

Hierdie boodskap en aanhangsels is aan 'n vrywaringsklousule
onderhewig. Volledige besonderhede is by
www.it.up.ac.za/documentation/governance/disclaimer/
beskikbaar.

[Buddy Moran]

Hi Marius,

Thank you very much for going through the effort of testing and diagnosing my project! I really appreciate it. I'll give your suggestion (starting with option 2) and share if it comes out successfully.

Regards,

Buddy

[Buddy Moran]

Hi Marius,

Here's the finished product. Thanks again for all your help.

Regards,

Buddy

[Mihkel Oviir]

Hi,

I was using Hugin in MacOS several years, but it fails now. Sierra 10.12.4, Hugin 2016.02 and 2017.0-alpha, both BTBatcherGUI and HuginStitchProject fail to stitch. Stitching just won't start. If I save project and open HuginStitchProject separately, I can stitch. Any ideas how to force Hugin to start stitching? No error messages occur, just silently failed.

[Niklas Mischkulnig]

Hello,

To find out why PTBatcher doesn't start in the first place, you need open Hugin in the Terminal, 

where it should give some more information:

1. Open Terminal.app
   
2. Drag Hugin.app from Finder into the Terminal window
   
3. Remove the space after .../Hugin.app and dd the following text to the command : /Contents/MacOS/Hugin 
   (if you put Hugin into Applications: /Applications/Hugin/Hugin.app/Contents/MacOS/Hugin )
4. Press enter
5. Try stitching them again in the now opening Hugin, it should say PTBatcherGui check returned value and then the path to PTBatcher

Please post the command output here.

[Amit Maitra]

Same question - here is the failure screen. system parameters captured at the bottom (in the failure window message)

Process:               PTBatcherGUI [866]

Path:                  /Applications/PTBatcherGUI.app/Contents/MacOS/PTBatcherGUI

Identifier:            PTBatcherGUI

Version:               2013.0.0 (e9df4bb31222)

Code Type:             X86-64 (Native)

Parent Process:        Hugin [835]

Responsible:           PTBatcherGUI [866]

User ID:               501

Date/Time:             2017-09-27 22:47:03.176 -0700

OS Version:            Mac OS X 10.12.6 (16G29)

Report Version:        12

Anonymous UUID:        4421961F-2B66-83A1-A3E7-8F29DBE82032

Time Awake Since Boot: 6400 seconds

System Integrity Protection: enabled

Crashed Thread:        0

Exception Type:        EXC_CRASH (SIGABRT)

Exception Codes:       0x0000000000000000, 0x0000000000000000

Exception Note:        EXC_CORPSE_NOTIFY

Termination Reason:    DYLD, [0x1] Library missing

Application Specific Information:

dyld: launch, loading dependent libraries

Dyld Error Message:

  Library not loaded: @executable_path/../Frameworks/libbase_wx-2013.0.dylib

  Referenced from: /Applications/PTBatcherGUI.app/Contents/MacOS/PTBatcherGUI

  Reason: image not found

Binary Images:

       0x100000000 -        0x10005afff +net.sourceforge.hugin.PTBatcherGUI (2013.0.0 - e9df4bb31222) <B63D1A34-4F96-35BD-8C22-7AE6E3312A0B> /Applications/PTBatcherGUI.app/Contents/MacOS/PTBatcherGUI

       0x108e3a000 -        0x108e77dc7  dyld (433.5) <322C06B7-8878-311D-888C-C8FD2CA96FF3> /usr/lib/dyld

    0x7fffb2f0f000 -     0x7fffb33a2fff  com.apple.CoreFoundation (6.9 - 1349.8) <36385A3A-60D3-32DB-BF55-C6D8931A7AA6> /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation

Model: MacBookPro9,2, BootROM MBP91.00D3.B22, 2 processors, Intel Core i5, 2.5 GHz, 8 GB, SMC 2.2f44

Graphics: Intel HD Graphics 4000, Intel HD Graphics 4000, Built-In

Memory Module: BANK 0/DIMM0, 4 GB, DDR3, 1600 MHz, 0x80CE, 0x4D34373142353237334348302D594B302020

Memory Module: BANK 1/DIMM0, 4 GB, DDR3, 1600 MHz, 0x80CE, 0x4D34373142353237334348302D594B302020

AirPort: spairport_wireless_card_type_airport_extreme (0x14E4, 0xF5), Broadcom BCM43xx 1.0 (7.21.171.130.1a1)

Bluetooth: Version 5.0.5f1, 3 services, 27 devices, 1 incoming serial ports

Network Service: Wi-Fi, AirPort, en1

Serial ATA Device: TOSHIBA MK5065GSXF, 500.11 GB

Serial ATA Device: HL-DT-ST DVDRW  GS31N

USB Device: USB 2.0 Bus

USB Device: Hub

USB Device: Hub

USB Device: Apple Internal Keyboard / Trackpad

USB Device: IR Receiver

USB Device: BRCM20702 Hub

USB Device: Bluetooth USB Host Controller

USB Device: USB 2.0 Bus

USB Device: Hub

USB Device: FaceTime HD Camera (Built-in)

USB Device: USB 3.0 Bus

Thunderbolt Bus: MacBook Pro, Apple Inc., 25.1

[Niklas Mischkulnig]

It looks like the PTBatcher program is damaged and you're using Hugin 2013, please update to the latest version (https://sourceforge.net/projects/hugin/files/latest/download?source=files).

Make sure to delete all Hugin apps (Hugin, PTBatcherGUI, HuginStitchProject, calibrate_lens_gui) from your /Applications folder before installing a new version.

Niklas

[Amit Maitra]

I am using the absolute latest greatest - deleted prior versions and installed fresh ones. 

Is there a way to verify the PTBatcherGUI installation independently?

Thanks in advance.

Amit

[Niklas Mischkulnig]

You should be able to start PTBatcherGUI.app just like Hugin.app . They should both be in the folder /Applications/Hugin/, if you pulled the Hugin folder onto the right icon during the installation.

Niklas

[Amit Maitra]

This is the o/p I see.

LSOpenURLsWithRole() failed for the application /Applications/PTBatcherGUI.app with error -10810.

LSOpenURLsWithRole() failed for the application /Applications/PTBatcherGUI.app with error -10810.

PTBatcherGui check returned  value /Applications/PTBatcherGUI.app/Contents/MacOS/PTBatcherGUI

dyld: Library not loaded: @executable_path/../Frameworks/libbase_wx-2013.0.dylib

  Referenced from: /Applications/PTBatcherGUI.app/Contents/MacOS/PTBatcherGUI

  Reason: image not found

ERROR: 03:08:11.152462 (/Users/niklas/development/release/hugin/src/hugin1/hugin/ProjectionGridTool.cpp:353) createTexture(): GL Error when building mipmap levels: invalid framebuffer operation.

ERROR: 03:08:11.325444 (/Users/niklas/development/release/hugin/src/hugin1/hugin/ProjectionGridTool.cpp:353) createTexture(): GL Error when building mipmap levels: invalid framebuffer operation.

ERROR: 03:08:11.454934 (/Users/niklas/development/release/hugin/src/hugin1/hugin/ProjectionGridTool.cpp:353) createTexture(): GL Error when building mipmap levels: invalid framebuffer operation.

PTBatcherGui check returned  value /Applications/PTBatcherGUI.app/Contents/MacOS/PTBatcherGUI

dyld: Library not loaded: @executable_path/../Frameworks/libbase_wx-2013.0.dylib

  Referenced from: /Applications/PTBatcherGUI.app/Contents/MacOS/PTBatcherGUI

  Reason: image not found

Amit

On Wednesday, May 10, 2017 at 7:26:41 AM UTC-7, Niklas Mischkulnig wrote:

[Niklas Mischkulnig]

It looks like the PTBatcher program is damaged and you're using Hugin 2013, please update to the latest version (https://sourceforge.net/projects/hugin/files/latest/download?source=files).
Make sure to delete all Hugin apps (Hugin, PTBatcherGUI, HuginStitchProject, calibrate_lens_gui) from your /Applications folder before installing a new version.

You are still using a old PTBatcherGUI version (but a more recent Hugin version as it seems). 

1. Look through your Applications folder and delete anything that looks like Hugin (i.e., a folder called Hugin, PTBatcherGUI.app and Hugin.app).
   
2. Open the Hugin 2017 dmg and drag the left icon onto the right to install Hugin (and PTBatcher).

Niklas

[Mikko Kuutti]

Hi,

I've had the same problem for quite a while, and have lazily just kept using the 2016 build because the 2017 version just would not start batches.

Anyway, I just looked into the issue, and found a fix:

xattr -dr com.apple.quarantine ./Hugin.app

That is, I navigated to the installation directory and removed the quarantine attribute. This, I've learned, stops what is called App Translocation, which otherwise would run the Hugin executable from an unknown location, breaking its ability to run the external apps.

I hope I've not restated the obvious but I could not find the solution posted earlier. I hope some others can benefit from this fix until Hugin is clever enough to work around this phenomenon. Thank Niklas for all your work, by the way.

Mikko

[Mihkel Oviir]

Thanks! I have been struggling with this for years. I was lazy and just saved my Hugin project and open it with HuginStitchProject separately. After every Hugin update I hoped, that this issue has fixed. Today I installed 2018 and still no luck. Running this line in Terminal, fixed it completely.

[Amit Maitra]

[Amit Maitra]

What is the syntax for running the HuginStitchProject with the .pto file?

[Amit Maitra]

Seems like the .tif interim files are not getting created.

My setup used to work before - now 2019 + Catalina OS has messed it up.

============================================

Stitching panorama…

============================================

Platform: macOS Version 10.15.1 (Build 19B88)

Version: 2019.0.0.a369cbe55179 built by Niklas Mischkulnig

Working directory: /Users/amitmaitra/Documents/MyPictures/2018/American Southwest/Thanksgiving 2018/Glen Canyon Recreation Area/Pano I/JPG/Left Half

Output prefix: IMG_2085 - IMG_2090

Blender: enblend 4.2.1-f0304648cc0f

ExifTool version: 11.26

Number of active images: 6

Output exposure value: 13.5

Canvas size: 9604x4718

ROI: (0, 878) - (9552, 4710) 

FOV: 45x23

Projection: Rectilinear(0)

Using GPU for remapping: true

Panorama Outputs:

* Exposure corrected, low dynamic range

First input image

Number: 0

Filename: /Users/amitmaitra/Documents/MyPictures/2018/American Southwest/Thanksgiving 2018/Glen Canyon Recreation Area/Pano I/JPG/Left Half/IMG_2085.JPG

Size: 5472x3648

Projection: Normal (rectilinear)

Response type: custom (EMoR)

HFOV: 19

Exposure value: 13.3

Remapping LDR images…

nona: using graphics card: ATI Technologies Inc. AMD Radeon Pro 560X OpenGL Engine

Multiple images output

loading IMG_2085.JPG

remapping IMG_2085.JPG

saving IMG_2085 - IMG_20900000.tif

loading IMG_2086.JPG

remapping IMG_2086.JPG

saving IMG_2085 - IMG_20900001.tif

loading IMG_2087.JPG

remapping IMG_2087.JPG

saving IMG_2085 - IMG_20900002.tif

loading IMG_2088.JPG

remapping IMG_2088.JPG

saving IMG_2085 - IMG_20900003.tif

loading IMG_2089.JPG

remapping IMG_2089.JPG

saving IMG_2085 - IMG_20900004.tif

loading IMG_2090.JPG

remapping IMG_2090.JPG

saving IMG_2085 - IMG_20900005.tif

Blending images...

enblend: failed to open "IMG_2085 - IMG_20900000.tif": No such file or directory

[Vegard Brenna]

I had the same problem. Try disabling the GPU. Worked for me.

On 22 Nov 2019, at 09:02, Amit Maitra <ama...@gmail.com> wrote:

Seems like the .tif interim files are not getting created.

My setup used to work before - now 2019 + Catalina OS has messed it up.

============================================

Stitching panorama…

============================================

Platform: macOS Version 10.15.1 (Build 19B88)

Version: 2019.0.0.a369cbe55179 built by Niklas Mischkulnig

Working directory: /Users/amitmaitra/Documents/MyPictures/2018/American Southwest/Thanksgiving 2018/Glen Canyon Recreation Area/Pano I/JPG/Left Half

Output prefix: IMG_2085 - IMG_2090

Blender: enblend 4.2.1-f0304648cc0f

ExifTool version: 11.26

Number of active images: 6

Output exposure value: 13.5

Canvas size: 9604x4718

ROI: (0, 878) - (9552, 4710) 

FOV: 45x23

Projection: Rectilinear(0)

Using GPU for remapping: true

Vegard Brenna
veg...@online.no

[Amit Maitra]

Interestingly, if I start PTBatcher gui independently and start Hugin inside it - it seems to work!

[AKS-Gmail-IMAP]

This is something we have been seeing with Catalina OS. For me the stitching works fine, and very fast btw, if I drag the pto file into the PTBatcher gui list box. Trying to load the pto into PTBatcher using its File Add results in a fail that has some odd missing tiff file messages posted in the PTBatcher list box in addition to a “hugin Error” form that is NOT hung. That error message is an “error while parsing panotools script:<the temp dir etc. etc.>/T/AppTranslocation/<what looks like a random dir name>…”. 

The path to the missing panotools script is too long to see (and I would not know what such script looks like), but if I look down that “/AppTranslocation/" trail it appears to be a folder with pointers to various Libraries, MacOS, and Resources. It looks to my untrained eye that the symlinks to needed componants in these files at /private/var/folders….etc are pointing to the /private/var/folders… etc location instead of their proper location within the Hugin application bundle.

--
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/cb07b9bf-ef62-4551-aed7-38e034b15652%40googlegroups.com.

[AKS-Gmail-IMAP]

Regarding the Catalina behavior I just mentioned when PTBatcher fails when manually loading a pto, the failed pto does not register at all in the PTBatcher list box. Normally one would see the pro project as failed. Instead, I know this sounds crazy, I see three list box entries each as "File missing” status, where the Output prefix listing (normally a file name) is actually a line from the temporary “huginpto_vtxRY9” file at the Hugin temp directory /private/var/folders/sw/<a random>/T folder. I am sure you Hugin programmers should be able to run with this information. That temp file with script instructions is being parsed as if the text lines in that file are file names instead of the normal stitching commands.

--
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/20678f1a-e17f-4954-bb64-d03786552302%40googlegroups.com.

[T. Modes]

Am Sonntag, 24. November 2019 04:13:20 UTC+1 schrieb aks:

I am sure you Hugin programmers should be able to run with this information. That temp file with script instructions is being parsed as if the text lines in that file are file names instead of the normal stitching commands.

No, that don't help further.

When you press "stitch now" the pto file is saved by Hugin.

Then PTBatcherGUI is called with the filename of the pto file and the selected prefix like

PTBatcherGUI /path/to/pto/file /path/to/prefix

Then PTBatcherGUI starts and reads the filename and prefix from it command line parameters and add the pto file to its internal queue.

This works fine on Windows and Linux and also on older Mac OS/X for years.

So I don't understand how PTBatcherGUI gets the *content* of the pto file instead of the filename of the pto file as command line parameters.

This seems very special to Mac OS Catalina. So I don't know what Apple changed here.

[AKS-Gmail-IMAP]

So I don't understand how PTBatcherGUI gets the *content* of the pto file instead of the filename of the pto file as command line parameters.

This seems very special to Mac OS Catalina.

It is so special that I cannot see that crazy behavior tonight! What I do see is OS X running Hugin and PTBatcherGUI in individual disk image randomized paths at /private/var/folders/[yaddayadda]/AppTranslocation/ T/AppTranslocation/[random_disk_image_name]. The entire Hugin application bundle appears within a random_disk_image different from where the random_disk_image the PTBatcherGUI application bundle resides. Apparently this “AppTranslocation” is a security mechanism introduced a few years ago. Maybe Catalina changed something with that. The various error messages have been related to unresolved paths.

It looks to me that PTBatcherGUI writes a temporary copy of the current pto file it is starting to process named as “huginpto_<6 random characters>”. It also writes the PTBatcherGUI-<user>.lock lock file. These files are placed at /private/var/folders/[yaddayadda]/T/. PTBatcherGUI removes those two files after a normal completed stitch. The pto “huginpto_<6 random characters>” files for failed/hung stitch projects are not cleaned up. They persist, I think until the next reboot.

As we currently see with Catalina, initiating a Stitch! from within Hugin results in a hung PTBatcherGUI with the error message “Failed to get working directory (error 2: No such file or directory)”. When this happens, I can clearly see from the Finder that the AppTranslocation random_disk_image to hold the PTBatcherGUI bundle has yet to be created. It looks like that might be causing the unresolved path problem. (Incidentally for those wondering how to see these hidden files, the keyboard shortcut Shift+Command+. in Catalina toggles the Finder to show the hidden items.) 

You might recall in previous postings I mentioned that sometimes the workaround I was using did not work if I did the steps too fast. I have noticed a slight delay in time until the AppTranslocation random_disk_image appears in the finder. Maybe it is the Finder catching up or maybe there actually is a delay that sometimes results in the working file paths not ready in time.

--
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/c12ac64a-6bcf-4377-95ec-e6687fe6e70a%40googlegroups.com.

[Niklas Mischkulnig]

Moving the application bundle in the Finder should (at least it has in the past) disable App Translocation. Running these two commands in the terminal should disable that for sure:
xattr -dr com.apple.quarantine /Applications/Hugin/Hugin.app
xattr -dr com.apple.quarantine /Applications/Hugin/PTBatcherGUI.app

Am Montag, 25. November 2019 03:56:31 UTC+1 schrieb aks:

So I don't understand how PTBatcherGUI gets the *content* of the pto file instead of the filename of the pto file as command line parameters.

This seems very special to Mac OS Catalina.

It is so special that I cannot see that crazy behavior tonight! What I do see is OS X running Hugin and PTBatcherGUI in individual disk image randomized paths at /private/var/folders/[yaddayadda]/AppTranslocation/ T/AppTranslocation/[random_disk_image_name]. The entire Hugin application bundle appears within a random_disk_image different from where the random_disk_image the PTBatcherGUI application bundle resides. Apparently this “AppTranslocation” is a security mechanism introduced a few years ago. Maybe Catalina changed something with that. The various error messages have been related to unresolved paths.

It looks to me that PTBatcherGUI writes a temporary copy of the current pto file it is starting to process named as “huginpto_<6 random characters>”. It also writes the PTBatcherGUI-<user>.lock lock file. These files are placed at /private/var/folders/[yaddayadda]/T/. PTBatcherGUI removes those two files after a normal completed stitch. The pto “huginpto_<6 random characters>” files for failed/hung stitch projects are not cleaned up. They persist, I think until the next reboot.

As we currently see with Catalina, initiating a Stitch! from within Hugin results in a hung PTBatcherGUI with the error message “Failed to get working directory (error 2: No such file or directory)”. When this happens, I can clearly see from the Finder that the AppTranslocation random_disk_image to hold the PTBatcherGUI bundle has yet to be created. It looks like that might be causing the unresolved path problem. (Incidentally for those wondering how to see these hidden files, the keyboard shortcut Shift+Command+. in Catalina toggles the Finder to show the hidden items.) 

You might recall in previous postings I mentioned that sometimes the workaround I was using did not work if I did the steps too fast. I have noticed a slight delay in time until the AppTranslocation random_disk_image appears in the finder. Maybe it is the Finder catching up or maybe there actually is a delay that sometimes results in the working file paths not ready in time.

On Nov 24, 2019, at 3:59 AM, T. Modes <Thoma...@gmx.de> wrote:

Am Sonntag, 24. November 2019 04:13:20 UTC+1 schrieb aks:

I am sure you Hugin programmers should be able to run with this information. That temp file with script instructions is being parsed as if the text lines in that file are file names instead of the normal stitching commands.

No, that don't help further.

When you press "stitch now" the pto file is saved by Hugin.

Then PTBatcherGUI is called with the filename of the pto file and the selected prefix like

PTBatcherGUI /path/to/pto/file /path/to/prefix

Then PTBatcherGUI starts and reads the filename and prefix from it command line parameters and add the pto file to its internal queue.

This works fine on Windows and Linux and also on older Mac OS/X for years.

So I don't understand how PTBatcherGUI gets the *content* of the pto file instead of the filename of the pto file as command line parameters.

This seems very special to Mac OS Catalina. So I don't know what Apple changed here.

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

[AKS-Gmail-IMAP]

Thank you for that information. I used it to remove the extended attribute in both applications and confirmed that indeed the AppTranslocation was not happening. The Catalina problem remains where the Stitch! operation started within Hugin results in PTBatcherGUI hanging with an error pane complaining "failed to get the working directory”.

Assume the “working directory” is the same as the “working directory” reported in the PTBatcherGUI’s verbose output pane. This directory is the folder holding the pto file. Clearly PTBatcherGUI can resolve that directory in all the other ways PTBatcherGUI receives a pto project file besides how it tries to resolve it when it is passed as an application startup argument from Hugin. In other words the Catalina problem only shows up when PTBatcherGUI is not already running.

By the way, PTBatcherGUI’s project list is already properly populated with the correct pathnames when the problem happens and in fact the problem happens prior to the “overwrite message”, which is never reached in the code, but after the PTBtacherGUI lock file and the huginpto_<random> files are created in the /private/…./T folder. There is a third random named file that normally would be created but is not. This is the small text file that has lines starting with hyphens. One can force quit the application and rerun PTBatcherGUI. At that point BTBatcherGUI remembers the project as failed and will successfully stitch it if one “resets” the project. PTBatcheGUI recreates the huginpto_<random> file and creates the small random name text file that has lines starting with hyphens. These appear before any “overwrite message”.

[Federico Feroldi]

Hello,

were you able to do it?

I just had the very same problem and I was able to make it work:

1) I started the assemble and got the error

2) I forced the closing of PTBatcherGUI

3) From Hugin menu I selected the last item in File menu and I pressed the green start button.

I don't know how, but it worked!