On Thursday, 22 September 2016 at 17:49:59 +0200, Stefan Peter wrote: > Hi Greg > > On 22.09.2016 03:46, Greg 'groggy' Lehey wrote: >> On Wednesday, 21 September 2016 at 21:00:56 +0200, Stefan Peter wrote: >>> On 20.09.2016 13:32, Michael Havens wrote: >>>> Okay, I'm running the stitcher now even though no control points were >>>> found. >>> >>> However, I was not able to recreate this problem here. Not even >>> using a non existent directory as temporary file location interfered >>> with creating control points. >> >> OK, that's interesting. I thought it once worked for me too. What >> platform and version of Hugin? > > I tested this with > ... enough versions > > All test were conducted under Ubuntu Xenial (16.04 LTS). > > All behaved exactly the same: > o No version tested had any problems finding cpfind > when there was a "Temporary dir" set in the preferences.
This is very interesting.
> o When creating CPs, the system defined /tmp/ was used.
What went in there? I see a couple of PTO files, nothing that is
likely to fill the file system.
> o When stitching (using PTBatcherGUI) I noticed two files
> (12k to 16k and 528 bytes) in the /hom/stefan/temp/ directory
> I put into the "Temporary dir" settings in the
> preferences.
That sounds like exactly these files.
> All other files were created in the projects directory.
This also matches my experience.
> So, where does this leave us?
>
> Obviously, your FreeBSD and Michaels Linux Mint (?) versions differ
> in some respect from the Ubuntu versions. Michaels version tends to
> clobber the /tmp/ directory
So far we have no evidence of that. I'm trying hard, but it's an
uphill battle.
> and both of your versions seem to have an issue when the Temprary
> dir is set on the preferences.
Yes.
> My first suspicion would be the libraries used. When building for Ubuntu
> which itself is based upon the Debian packages, there are quite some
> dependency requirements in the form of
> libboost-filesystem-dev (>= 1.47)
> This means that building Hugin will fail of libboost-filesystem with a
> version >= 1.47 is not available. The reason for such version
> requirements may be caused by functionality used by Hugin which is not
> present in earlier versions. Or known bugs in earlier versions that may
> affect Hugins functionality. So, for starters, lets compare the
> libraries used in these three versions. Attached you find the output of
> ldd $(which hugin)
> for the aforementioned hugin 2016.2.0 be8da0221960 (not officially
> released by me yet). Would you please be so kind and compare the output
> produced on your systems and let me know the differences?
I'm prepared to blame libraries for lots of things, but I can't think
of a scenario where one could cause this kind of problem. Still, I've
compared the two ldd outputs (sorted, trimmed path names), and we
have:
--- ldd-freebsd-sorted 2016-09-23 09:03:16.109044000 +1000
+++ ldd-ubuntu-sorted 2016-09-23 09:02:31.692945000 +1000
@@ -1,14 +1,12 @@
- libEGL.so.1
+ /lib64/ld-linux-x86-64.so.2 (0x000055a058713000)
libGL.so.1
- libGLEW.so.1
+ libGLEW.so.1.13
libGLU.so.1
libHalf.so.12
libICE.so.6
libIex-2_2.so.12
- libIexMath-2_2.so.12
libIlmImf-2_2.so.22
libIlmThread-2_2.so.12
- libImath-2_2.so.12
libSM.so.6
libX11-xcb.so.1
libX11.so.6
@@ -23,93 +21,64 @@
libXinerama.so.1
libXrandr.so.2
libXrender.so.1
- libXt.so.6
libXxf86vm.so.1
libatk-1.0.so.0
- libboost_filesystem.so.1.55.0
- libboost_system.so.1.55.0
- libbz2.so.4
- libc++.so.1
- libc.so.7
+ libboost_filesystem.so.1.58.0
+ libboost_system.so.1.58.0
+ libc.so.6
libcairo.so.2
libceleste.so.0.0
- libcxxrt.so.1
+ libdatrie.so.1
+ libdl.so.2
libdrm.so.2
- libelf.so.1
- libenchant.so.1
- libexecinfo.so.1
libexiv2.so.14
libexpat.so.1
libffi.so.6
libfftw3.so.3
libfontconfig.so.1
libfreetype.so.6
- libgbm.so.1
libgcc_s.so.1
- libgcrypt.so.20
libgdk-x11-2.0.so.0
libgdk_pixbuf-2.0.so.0
libgio-2.0.so.0
+ libglapi.so.0
libglib-2.0.so.0
libgmodule-2.0.so.0
libgobject-2.0.so.0
- libgpg-error.so.0
+ libgomp.so.1
libgraphite2.so.3
- libgstapp-1.0.so.0
- libgstaudio-1.0.so.0
- libgstbase-1.0.so.0
- libgstfft-1.0.so.0
- libgstpbutils-1.0.so.0
- libgstreamer-1.0.so.0
- libgsttag-1.0.so.0
- libgstvideo-1.0.so.0
- libgthread-2.0.so.0
libgtk-x11-2.0.so.0
- libharfbuzz-icu.so.0
libharfbuzz.so.0
- libhdf5.so.10
- libhdf5_hl.so.10
libhugin_python_interface.so.0.0
libhuginbase.so.0.0
libhuginbasewx.so.0.0
- libiconv.so.2
libicpfindlib.so.0.0
- libicudata.so.55
- libicui18n.so.55
- libicuuc.so.55
- libintl.so.8
- libjavascriptcoregtk-1.0.so.0
- libjbig.so.2
+ libjbig.so.0
libjpeg.so.8
liblcms2.so.2
liblzma.so.5
- libm.so.5
- libmspack.so.0
- libnvidia-glcore.so.1
- libnvidia-tls.so.1
- liborc-0.4.so.0
+ libm.so.6
+ libnotify.so.4
libpango-1.0.so.0
libpangocairo-1.0.so.0
libpangoft2-1.0.so.0
libpano13.so.3
- libpcre.so.1
+ libpcre.so.3
libpixman-1.so.0
- libpng16.so.16
- libpthread-stubs.so.0
- libpython2.7.so.1
- librpcsvc.so.5
+ libpng12.so.0
+ libpthread.so.0
+ libpython2.7.so.1.0
+ libresolv.so.2
librt.so.1
- libsecret-1.so.0
- libsoup-2.4.so.1
+ libselinux.so.1
libsqlite3.so.0
- libthr.so.3
+ libstdc++.so.6
+ libthai.so.0
libtiff.so.5
- libutil.so.9
+ libutil.so.1
+ libuuid.so.1
libvigraimpex.so.5
- libwebkitgtk-1.0.so.0
- libwebp.so.5
libwx_baseu-3.0.so.0
- libwx_baseu_net-3.0.so.0
libwx_baseu_xml-3.0.so.0
libwx_gtk2u_adv-3.0.so.0
libwx_gtk2u_aui-3.0.so.0
@@ -119,11 +88,13 @@
libwx_gtk2u_qa-3.0.so.0
libwx_gtk2u_xrc-3.0.so.0
libxcb-dri2.so.0
+ libxcb-dri3.so.0
+ libxcb-glx.so.0
+ libxcb-present.so.0
libxcb-render.so.0
- libxcb-shape.so.0
libxcb-shm.so.0
- libxcb-xfixes.so.0
+ libxcb-sync.so.1
libxcb.so.1
- libxml2.so.2
- libxslt.so.1
- libz.so.6
+ libxshmfence.so.1
+ libz.so.1
+ linux-vdso.so.1
That's actually a surprising number of differences. If you have some
reason to suspect libboost, it's interesting to note the difference
there. But it's still way higher than 1.47.
>> I modified icpfind to find what it was looking for. It had an empty
>> PATH variable, so it couldn't find the control point detector.
>
> Sorry, this I don't get. icpfind _is_ the control point detector.
No, icpfind starts the control point detector. In my case it was
looking for panomatic, in Michael's case cpfind.
> If it gets found, it should work. If it does not get found, how do
> you determine the PATH environment variable it was called with?
Here's the function in question
(hugin-2016.2.0/src/hugin1/icpfind/AutoCtrlPointCreator.cpp, round
line 191):
bool CanStartProg(wxString progName,wxWindow* parent)
{
#if defined MAC_SELF_CONTAINED_BUNDLE
if(!GetBundledProg(progName).IsEmpty())
return true;
#endif
wxFileName prog(progName);
bool canStart=false;
if(prog.IsAbsolute())
{
canStart=(prog.IsFileExecutable());
}
else
{
wxPathList pathlist;
#ifdef __WXMSW__
const wxFileName exePath(wxStandardPaths::Get().GetExecutablePath());
pathlist.Add(exePath.GetPath(wxPATH_GET_VOLUME | wxPATH_GET_SEPARATOR));
#endif
pathlist.AddEnvList(wxT("PATH"));
wxString path = pathlist.FindAbsoluteValidPath(progName);
if(path.IsEmpty())
canStart=false;
else
{
wxFileName prog2(path);
canStart=(prog2.IsFileExecutable());
};
};
if(!canStart)
CPMessage(wxString::Format(
_("Could not find \"%s\" in path.\nMaybe you have not installed it
properly or given a wrong path in the settings."),progName.c_str()),
_("Error"),parent);
return canStart;
};
My modification was:
if(path.IsEmpty())
{
canStart=false;
CPMessage(wxString::Format(_("No path set for executables.\n")),
_("Error"),parent);
}
else
{
wxFileName prog2(path);
canStart=(prog2.IsFileExecutable());
if(!canStart)
CPMessage(wxString::Format(
_("Could not find \"%s\" in path
\"%s\".\n"
"Maybe you have not installed it
properly or given a wrong path in the settings."),
progName.c_str(), path),
_("Error"),parent);
};
I wanted to display the path, but it's all tied up in wxString and
other complications that I don't understand, so I've given up for the
moment. But the message I got showed that the path was empty.
>> And yes, I'm still planning to track the bug down.
>
> Yes, so do I. After all, it may come back and bite me in a future
> version, too.
Let me know if I can get you any more information.
Greg
--
Sent from my desktop computer.
Finger g...@freebsd.org for PGP public key.
See complete headers for address and phone numbers.
This message is digitally signed. If your Microsoft mail program
reports problems, please read http://lemis.com/broken-MUA
--
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/20160922234034.GH49504%40eureka.lemis.com.
For more options, visit https://groups.google.com/d/optout.
signature.asc
Description: PGP signature
