Hi,
Thanks for replying.
> Sorry, but I can't reproduce the issue. It works fine here also with
> non-ascii characters (tested on Fedora).
>
I'm using Debian 9, with the en_IL.utf8 locale. The steps I've taken to
reproduce the bug are:
1. Start a new project where the pto is in some non-ascii path and set the
output prefix to be in the same directory (with non-acii name).
2. Attempt to stitch.
3. hugin_stitch_project is executed and fails. I've attached the log it
shows.
If you strace hugin using an ascii path
$ strace -s 1000 -f -t -v -e trace=process -o huing_good.strace hugin /tmp/
hugin/abcd/IMG_0421\ -\ IMG_0421.pto
you can see the execve syscall that executes hugin_stitch_project:
execve("/usr/bin/hugin_stitch_project", ["hugin_stitch_project", "--delete",
"-o", "/tmp/hugin/abcd/IMG_0421 - IMG_0421", "/tmp/huginpto_WrUC2G"],...
However, doing the same but with a non-ascii path
strace -s 1000 -f -t -v -e trace=process -o huing.strace hugin /tmp/hugin
/אבגד/IMG_0421\ -\ IMG_0421.pto
results in the following:
execve("/usr/bin/hugin_stitch_project", ["hugin_stitch_project", "--delete",
"-o", "", "/tmp/huginpto_c4sLVF"],...
The empty argument to "-o" is than concatenated later on in the call to
'nona' which results in a missing parameter.
execve("/usr/bin/nona", ["/usr/bin/nona", "-v", "-z", "LZW", "-r", "ldr",
"-m", "TIFF_m", "-o", "/tmp/huginpto_w9GzzF"],
This is the same call but when the bug does not manifest itself.
execve("/usr/bin/nona", ["/usr/bin/nona", "-v", "-z", "LZW", "-r", "ldr",
"-m", "TIFF_m", "-o", "IMG_0421 - IMG_0421", "/tmp/huginpto_HoUdv9"],
As can be seen, the output prefix parameter is missing in the non-ascii
case.
> This is related to bug https://bugs.launchpad.net/hugin/+bug/678808 and
>> its duplicates.
>>
> Sorry, but this bug is Windows only and has nothing to do with wxExecute.
>
You are right, my mistake. I'll open a new bug report, sorry for the
inconvenience.
>
> After some debugging it turns out that the culprit is the call to
>> hugin_stich_project using wxExecute. wxExcute does a poor (buggy) handling
>> of converting the internal Unicode representation to UTF-8 and drops any
>> arguments containing non-ascii characters. The attached bug works around
>> it, and solves the issue.
>>
> If you think that this is a wxWidgets bug, then it should be reported and
> fixed upstreams in wxWidgets.
>
I do intend to report it and try to fix it there as well. But I think there
are two benefits for making a workaround in hugin:
1. You don't have to wait for a new wxWidgets release and then wait until
the new version becomes the default in different distros and hugin is built
against it.
2. It avoids unnecessary parsing and handling of the command line
arguments. The current method works by constructing a single string
containing all the arguments, requiring quoting filenames, and then letting
wxExecute break it up to separate arguments using
wxCmdLineParser::ConvertStringToArgs(),
only to call the version of wxExecute that gets an array of arguments. By
directly using that version of wxExecute, you both avoid unnecessary
parsing and fix the non-ascii issue.
> But until now nobody else on Linux reported this bug so far. So this is
> really strange and maybe related to some special configuration on your side.
>
> It might indeed be the case, but does it make it not worthwhile to fix if
the patch doesn't cause any other problems? :-)
> You have also only fixed the call to hugin_stitch_project but left the
> call of PTBatcherGUI, which is also called by wxExecute in a similar way.
>
>
You are right, I should probably fix all other calls to wxExecute which get
user input. I simply prefer to see if the proposed workaround will be
accepted before start working on every instance of wxExecute requiring
attention :-)
But I prefer to see if the intentions are to fix the issue before
committing more time to make the patches :-)
Thanks for you feedback,
Guy
--
A list of frequently asked questions is available at:
http://wiki.panotools.org/Hugin_FAQ
---
You received this message because you are subscribed to the Google Groups
"hugin and other free panoramic software" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to hugin-ptx+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/hugin-ptx/c657fd46-b015-4b4a-98b7-23be83063403%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
============================================
Stitching panorama...
============================================
Platform: Linux 4.9.0-3-amd64 x86_64
Version: 2017.0.0.eac5e8cc546e
Working directory: /tmp
Output prefix:
Blender: enblend 4.2
ExifTool version: 10.40
Number of active images: 1
Output exposure value: 13.6
Canvas size: 5194x3930
ROI: (105, 96) - (5089, 3834)
FOV: 39x30
Projection: Rectilinear(0)
Using GPU for remapping: false
Panorama Outputs:
* Exposure corrected, low dynamic range
First input image
Number: 0
Filename:
Size: 5184x3888
Projection: Normal (rectilinear)
Response type: custom (EMoR)
HFOV: 38
Exposure value: 13.6
Remapping LDR images...
nona: No project file given.
