enblend: error when first filename starts with -

[Volker K.]

I get the following error msg using
hugin 2010.4.0 on Mac OS 10.6.5.

Here's from the log:
...
enblend: unknown option "-U"
Try "enblend --help" for more information.
gnumake: *** [-Users-Volker-Desktop-Hugin Test-DSC_0067-DSC_0074.jpg] Error 1

At this point, hugin has written the modified source pictures for the panaorama to the desiered directory,
you can put them together manually using the gimp or something.
I also tried successfully to start emblend out of the hugin package via terminal and make it do the job from there. Worked fine, too.
to me it seems that the emblend gets a wrong input within hugin.
I am not into the depth of any programming, so this is as far as I could get. HTH.

[zarl (carl-einem)]

Somehow you have told enblend to use the command line argument "-U" which doesn't exist. Valid arguments are described here:
http://wiki.panotools.org/Enblend_reference_manual#Common_Options

There are two places in hugin where you can specify these arguments: General behaviour for all new projects via the preferences window (see http://wiki.panotools.org/Hugin_Preferences#Enblend for useful options); or specific arguments for the project you are just working on via the "Stitching" tab (press enblend's "option" button).

Just exchange the -U argument with something more useful (i.e. '-v' will output some extra information while enblend is merging your images) and stitch again.

[Bruno Postle (brunopostle)]

The problem is this filename: -Users-Volker-Desktop-Hugin

enblend thinks this is a command-line parameter because it starts with '-'. We don't have enough information to see exactly where this is happening, can you post the full log?

[Volker K. (volker-kukulenz)]

ok, here is the full log

===========================================================================
*************** Panorama makefile generated by Hugin ***************
===========================================================================
System information
===========================================================================
Software:

    System Software Overview:

      System Version: Mac OS X 10.6.5 (10H574)
      Kernel Version: Darwin 10.5.0
      Boot Volume: Macintosh HD
      Boot Mode: Normal
      Computer Name: Volker Kukulenzs MacBook Pro
      User Name: Volker Kukulenz (Volker)
      Secure Virtual Memory: Enabled
      64-bit Kernel and Extensions: No
      Time since boot: 31 days 4:19

Hardware:

    Hardware Overview:

      Model Name: MacBook Pro
      Model Identifier: MacBookPro5,3
      Processor Name: Intel Core 2 Duo
      Processor Speed: 2,66 GHz
      Number Of Processors: 1
      Total Number Of Cores: 2
      L2 Cache: 3 MB
      Memory: 4 GB
      Bus Speed: 1,07 GHz
      Boot ROM Version: MBP53.00AC.B03
      SMC Version (system): 1.48f2
      Serial Number (system): [...]
      Hardware UUID: [...]
      Sudden Motion Sensor:
          State: Enabled

Disc usage
Filesystem Size Used Avail Capacity Mounted on
/dev/disk0s2 298Gi 186Gi 112Gi 62% /
devfs 108Ki 108Ki 0Bi 100% /dev
map -hosts 0Bi 0Bi 0Bi 100% /net
map auto_home 0Bi 0Bi 0Bi 100% /home
===========================================================================
Output options
===========================================================================
Hugin Version: 2010.4.0 built by Harry van der Wolf
Project file: /var/folders/7I/7IkWhWezEsOpwlope3iXdE+++TI/-Tmp-/huginpto_t3Kh1W
Output prefix: -Users-Volker-Desktop-Hugin Test-DSC_0067-DSC_0074
Projection: Cylindrical (1)
Field of view: 210 x 42
Canvas dimensions: 11957 x 2505
Crop area: (454,509) - (11583,1993)
Output exposure value: 15.63
Selected outputs
Normal panorama
* Blended panorama
===========================================================================
Input images
===========================================================================
Number of images in project file: 8
Number of active images: 8
Image 0: /Users/Volker/Desktop/Hugin Test/DSC_0067.JPG
Image 0: Size 4288x2848, Exposure: 15.64
Image 1: /Users/Volker/Desktop/Hugin Test/DSC_0068.JPG
Image 1: Size 4288x2848, Exposure: 15.67
Image 2: /Users/Volker/Desktop/Hugin Test/DSC_0069.JPG
Image 2: Size 4288x2848, Exposure: 15.65
Image 3: /Users/Volker/Desktop/Hugin Test/DSC_0070.JPG
Image 3: Size 4288x2848, Exposure: 15.64
Image 4: /Users/Volker/Desktop/Hugin Test/DSC_0071.JPG
Image 4: Size 4288x2848, Exposure: 15.61
Image 5: /Users/Volker/Desktop/Hugin Test/DSC_0072.JPG
Image 5: Size 4288x2848, Exposure: 15.61
Image 6: /Users/Volker/Desktop/Hugin Test/DSC_0073.JPG
Image 6: Size 4288x2848, Exposure: 15.61
Image 7: /Users/Volker/Desktop/Hugin Test/DSC_0074.JPG
Image 7: Size 4288x2848, Exposure: 15.62
===========================================================================
Testing programs
=====================================================...

[Bruno Postle (brunopostle)]

Ok, this is the problem:

  Output prefix: -Users-Volker-Desktop-Hugin Test-DSC_0067-DSC_0074

Did Hugin suggest this for you when you went to stitch? If so the workaround is simply to edit the 'prefix' to remove the '-' at the beginning (you get a chance to edit the prefix when you click on the Stitch button).

I think this is a bug in Hugin if it suggests such a prefix, since it makes no sense.

There is also an enblend bug since a parameter like '-o -Users' is unambiguous, nona deals with this correctly as you can see in the log.

[Volker K. (volker-kukulenz)]

You are right, the prefix suggested by hugin caused the problem.
So this thing is solved for me :-)
Thank you very much for your help.

V.K.

[Bruno Postle (brunopostle)]

Why was this marked as invalid? this is clearly a Hugin bug (possibly only OS X) and an enblend bug.

[Yuv (yuv)]

it is definitely invalid in enblend. In Hugin it is a duplicate of bug #697039

[tmodes (tmodes)]

I changed the filename handling a bit. But I don't know if this fixes the wrong proposed filename.

[Bruno Postle (brunopostle)]

The enblend problem is with binary shipped in the Hugin Windows installer, on Linux I can use filenames begining with '-'.

So I assume the difference is between getopt.h in glibc and msvc.

[tmodes (tmodes)]

I tested further. The problem occurs on windows only if the first input filename start with -
Output filename starting with - is okay, also second input filename can start with -.

[aseidel (akseidel)]

This problem goes back to mid December 2009 and has affected every OSX issue since then including 2010.5.0-4886_a1cb4a2efa65. On OSX Intel Snow Leopard machines it manifests itself when using the Hugin stitcher when the pto file has already been saved as would be the case when re-stitching an existing project. Stitching on Leopard PPC machines fails also but without any shell residue to follow. Perhaps it is for the same reason. Note that in both cases the PTBatchGUI does not have the problem stitching.

What appears to be happening is that when the pto already exists Hugin suggests a filename that includes the full path of the existing pto file where the hyphen character "-" is substituted for every instance of the normal path separator character in the full pto pathname and also as the first character. It looks like this name is subsequently passed not as a quoted string to enblend, which in turn thinks the first hyphen indicates an enblend parameter "-U" because all the described above substituted full pathnames would start with "-User".

It is interesting that this does not happen on Intel Leopard machines when the pto is not existing or when a different name is types in that does not start with "-". However on Leopard PPC machines the stitch fails no matter what, even when on a totally fresh pto condition.

[Christoph Spiel (cspiel)]

This is not a bug, but standard UN*X behavior: options start with a dash;
GNU (long) options start with two dashes.

Every decent libc that implements getopt_long(3) ought to accept a
freestaning double-dash, i.e. `--' as option-end-marker.

Under Linux both Enblend and Enfuse honor this marker. So, you can
write e.g.,
    "enblend --verbose=2 --optimizer-weights=3:1 -c -- -foo.jpg -bar.jpg -baz.jpg"
to blend "-foo.jpg", "-bar.jpg", and "-baz.jpg".

[tmodes (tmodes)]

The makefile generation was changed to work with filenames which start with a dash.
It works for enblend, enfuse, hugin_hdrmerge.
But it does not work with exiftool because exiftool does not the follow the mentioned standard UN*X behavior. But this does not trigger an error.
As result all image files are generated, but they are missing the EXIF informations. Is this sufficient?