[OSX] New hugin-mac-2010.5.0-4854_d29b1d6da0e0 incl. Thoby projection, new cpfind and gsoc 2010 panorama projection
Harry van der Wolf
another new Hugin build.
This one contains:
- The Thoby projection (like the previous build)
- The gsoc 2010 panorama overview
- The new "flann enhanced" cpfind. This should make cpfind even better. Default cpfind settings remain the same AFAIK and tested.
If you find a bug, please register it in the hugin bugtracker [0].
Anything else: please report it to this mailing group.
This is again a triple architecture (i386/x86_64/ppc) univeral build
As always: Information and binaries via my website
<http://panorama.dyndns.org/index.php?lang=en&subject=Hugin&texttag=Hugin>.
(The binaries themselves are served from hugin.panotools.org who kindly provide the disk space and bandwidth).
Hoi,
Harry
[0]: <https://bugs.launchpad.net/hugin>
David Haberthür
On 17.01.2011, at 21:14, Harry van der Wolf wrote:
> Hi mac users,
>
> another new Hugin build.
>
> This one contains:
> - The Thoby projection (like the previous build)
> - The gsoc 2010 panorama overview
> - The new "flann enhanced" cpfind. This should make cpfind even better. Default cpfind settings remain the same AFAIK and tested.
Thanks again for your constant work with packaging hugin.
I really like the new panorama overview window with the Panoshpere
Will let the launchpad tracker know if I find any prominent bugs.
Habi
Habi
-> Stitching works flawlessly, but the filename encoding is wrong if
the filename contains an Umlaut
Habi
grow
As always thanks for all the work that you put into building Hugin.
I am not sure that this would be classed as a bug so I am mentioning
it here.
I downloaded this latest version and put it through its paces on a
stitch of 27 images (each 12Mp) in 9 stacks. The preview is looking
good but Control Point optimisation seems to be taking a long time.
It has been running for two hours as I type this.
It has got to the twelfth iteration of Strategy 2 and is reporting an
average distance of around 6 units which sounds healthy ...
It is optimising the control points placed by cpfind on the "top"
image from each stack. I had set CpFind to find 20 for each overlap
and then "excluded points on masks" and ran celeste before running
optimisation. I had already optimised control points on each stack.
I am going to leave it running for the moment and will come back here
later when it has finished.
George
phar...@gmail.com
> Harry,
> As always thanks for all the work that you put into building Hugin.
>
> I am not sure that this would be classed as a bug so I am mentioning
> it here.
>
> I downloaded this latest version and put it through its paces on a
> stitch of 27 images (each 12Mp) in 9 stacks. The preview is looking
> good but Control Point optimisation seems to be taking a long time.
> It has been running for two hours as I type this.
> It has got to the twelfth iteration of Strategy 2 and is reporting an
> average distance of around 6 units which sounds healthy ...
>
> It is optimising the control points placed by cpfind on the "top"
> image from each stack. I had set CpFind to find 20 for each overlap
> and then "excluded points on masks" and ran celeste before running
> optimisation. I had already optimised control points on each stack.
>
> I am going to leave it running for the moment and will come back here
> later when it has finished.
So, are you able to produce a stitched image from this latest
Macintosh version from Harry? I still cannot, and I am sure that
there are other Mac users who cannot. An error message that appears
at the stitching stage informs one of this:
echo: write: Bad file descriptor
gnumake: *** [info] Error 1
My question is this, if you will. What Mac system are you using and
what OS version, please. I am using a G5 Core 2 Duo running OS 10.5.4
on an iMac.
Thanks.
Steve
Harry van der Wolf
So, are you able to produce a stitched image from this latest
Macintosh version from Harry? I still cannot, and I am sure that
there are other Mac users who cannot. An error message that appears
at the stitching stage informs one of this:
echo: write: Bad file descriptor
gnumake: *** [info] Error 1
My question is this, if you will. What Mac system are you using and
what OS version, please. I am using a G5 Core 2 Duo running OS 10.5.4
on an iMac.
Thanks.
Steve
Jeffrey Martin
grow
Yes I finally got a good stitch.
I did have to leave the Optimise phase running overnight - it didn't
finish until after breakfast - it had done over 18 hours of
processing the last time I saw the progress bar. (It had been keeping
one of my cores at 100%.)
As for the filename problem ... I have a standard procedure which is
to have each panorama project in a folder of its own, where I keep the
".pto" file and I have sub-folders: called:
"Source" for the Raw source images from the camera,
"Select" for the Tiff files of the selection of images I am going to
use,
"Final" for the stitched images,
I create sub-folders in Final called "Take_01", "Take_02" and so on
- one for each stitch of a particular project. I name the output
file of a particular stitch by combining the project name and the
"take" number. So if the pto file was called "project" the first time
I stitched it the output file would be called "project_01".
"Print" where I keep printable images.
I also usually have a text file called "Notes" where I keep notes on
the progress/status of the project.
If I do some sort of experiment with parameters and want to be able to
roll-back I would save a copy of the project file with the take number
on the end.
Over the years I have found that system to be helpful for managing all
the files and keeping track of which projects generated which stitch.
It has also had the happy side-effect of avoiding this file naming
problem.
I have downloaded Harry's new version (while typing this) and will
give it a try later on today.
George
On Jan 19, 2:27 am, "phartz...@gmail.com" <phartz...@gmail.com> wrote:
phar...@gmail.com
> Steve,
>
> Yes I finally got a good stitch.
Thanks for your reply and your offerings about how one might go
about organizing pano projects.
Which OS version are you using? I run 10.5.4 which worked fine for
me with the various Hugin versions up until 2010.3. as I recall, which
is when this "file descriptor" thing began to raise its ugly head. I
have followed Harry's suggestions as to how to remedy it, but nothing
is working for me.
I am beginning to wonder if it is related to peculiarities of
varying operating system versions.
Steve
grow
I am on 10.6.6 now. I updated my Mac a few months ago after my
venerable PowerMac G5 machine had a fatal hardware problem.
I am a bit puzzled as to which machine you are running. You say "G5
Core 2 Duo" but "G5", normally applies to PowerMac (or iMac) models
using a PowerPC processor and "Core 2 Duo" is usually applied to Intel
based machines such as the "Mac Pro" (or recent iMacs).
I understand your frustrations. When I was using the PowerMac G5 I
did sometimes have to struggle with being in a dwindling minority
where there were fewer and fewer of us to find the quirks that applied
to our architecture.
George
On Jan 19, 12:40 pm, "phartz...@gmail.com" <phartz...@gmail.com>
wrote:
phar...@gmail.com
> Hi Steve,
> I am on 10.6.6 now. I updated my Mac a few months ago after my
> venerable PowerMac G5 machine had a fatal hardware problem.
>
> I am a bit puzzled as to which machine you are running. You say "G5
> Core 2 Duo" but "G5", normally applies to PowerMac (or iMac) models
> using a PowerPC processor and "Core 2 Duo" is usually applied to Intel
> based machines such as the "Mac Pro" (or recent iMacs).
>
> I understand your frustrations. When I was using the PowerMac G5 I
> did sometimes have to struggle with being in a dwindling minority
> where there were fewer and fewer of us to find the quirks that applied
> to our architecture.
Sorry for the confusion. I am using a recent Intel iMac, Core 2
Duo, OS 10.5.4. I think that Harry is now using 10.6 as are you.
I would be interested to find out if this "bad file descriptor"
problem is related to the OS version in use, and I am beginning to
think that it is. I have tried everything that I can think of,
including of course Harry's suggestions, but to no avail. All is well
until I try to stitch, wherein the failure occurs, resulting in the
"bad file descriptor" message. Additionally, it appears as though the
bug that requires path names where the application resides to be free
of any spaces has resurfaced. That had been a problem in some earlier
releases, but had vanished in the 2010.2 release, or even a bit
earlier as I recall.
If this "file descriptor" based failure cannot be found and fixed,
and if it is causing the same failure for other Mac users, that would
not bode well. I have no real idea of how many are seeing this issue,
but I would be very interested in hearing from others on this.
Steve
Stefan Peter
Am 19.01.2011 03:27, schrieb phar...@gmail.com:
> On Tue, Jan 18, 2011 at 10:19 AM, grow <geor...@gmail.com> wrote:
>
>
> echo: write: Bad file descriptor
> gnumake: *** [info] Error 1
>
I'm not a mac user myself, so please take this with a grain of salt:
This error message has been emitted by gnu make. Now, the error message
itself seems to originate from echo, a small utility you find as
/bin/echo in most unix systems.
Inspecting the <panoname>.pto.mk generated by hugin shows that echo is
used to provide feedback concerning the progress and eventual errors.
When using the "Stitch now" button in hugin, a window is opened that
will be used to display these messages.
The sole purpose of this echo utility is to display text in a console.
Could it be possible that, probably only this one special version from
mac os 10.5.4 has a problem emitting text not to a physical console, but
a wx console widget (or whatever it is called)?
Some tests may clarify this
o Try to send your project to the batch processor (I hope this
does exist in the mac version of hugin, too). Make sure
you have disabled the "Verbose output" option
o Open a shell, change to the project directory, and use
"make -f <projectname>.pto.mk"
to start the stitching
If one of these tests are successful, the echo utility may be the culprit.
With kind regards
Stefan Peter
--
In theory there is no difference between theory and practice. In
practice there is.
phar...@gmail.com
Sir, you are a scholar, and I thank you. I downloaded the Macintosh
"ptbatcher" GUI having not previously needed it or having ever used
it. I loaded my .pto file into the batch processor, and voila,
obtained a fine stitched pano output image. Your above theory seems
to be quite correct, and because I was thinking the problem was
related to a specific OS version, we appear to both be vindicated.
myself with my suspicion and yourself with your solution.
Hopefully, this workaround can be eliminated through finding a means
that will enable the Hugin application to be able to stitch regardless
of peculiarities that may appear between various recent versions of
the Macintosh operating system. In the meantime, other Mac users
having similar difficulties should take note.
Again, thanks.
Steve
Bruno Postle
>Am 19.01.2011 03:27, schrieb phar...@gmail.com:
>> On Tue, Jan 18, 2011 at 10:19 AM, grow <geor...@gmail.com> wrote:
>>
>> echo: write: Bad file descriptor
>> gnumake: *** [info] Error 1
>This error message has been emitted by gnu make. Now, the error message
>itself seems to originate from echo, a small utility you find as
>/bin/echo in most unix systems.
In most shells 'echo' is a built-in command and /bin/echo is similar
but different. So the behaviour will depend on the default shell,
or the origin of the /bin/echo tool, or both (which could vary
between OS X releases).
The .pto.mk file assumes that the shell is 'bash', so this problem
could be fixable by forcing the shell in the .pto.mk file:
SHELL=/bin/bash
(we should maybe do this anyway)
If this doesn't work, something else to try would be forcing the
echo command instead:
ECHO=/bin/echo
--
Bruno
Stefan Peter
> In most shells 'echo' is a built-in command and /bin/echo is similar but
> different. So the behaviour will depend on the default shell, or the
> origin of the /bin/echo tool, or both (which could vary between OS X
> releases).
>
> The .pto.mk file assumes that the shell is 'bash', so this problem could
> be fixable by forcing the shell in the .pto.mk file:
>
> SHELL=/bin/bash
>
> (we should maybe do this anyway)
At least in linux systems, you can not (anymore) assume that the default
shell is bash. Most debian derived systems nowadays use dash as the
default command line interpreter and if you want to have bash, you will
need to install it separately.
In quite some projects I'm aware of, massive chunks of shell code are
(or have been) scrutinized for so called bashisms in oder to make sure
they can be used on systems without an installed bash.
Therefore, building a dependency for hugin on bash does not seem to be
recommended.
Anyway, whether echo is a builtin or an external utility, in both cases
it should be capable to work with wxWidgets. If not, either the shell
providing the echo builtin, the /bin/echo utility or wxWidget are at
fault. And if I got the problem correctly, this seems to be the case
with mac os 10.5.4 used by Steve, but not with the mac os used by George
or Harry.
> If this doesn't work, something else to try would be forcing the echo
> command instead:
>
> ECHO=/bin/echo
>
This would select the external echo utility in favor of the (eventually)
built in echo functionality of the shell in charge. In order to
definitely getting rid of this, "ECHO=/bin/true"" could be used.
However, in this case all terminal output is suppressed. This includes
eventual error messages.
Harry van der Wolf
AFAIK the default shell is bash by default since Tiger.
@Steve:
Can you open a terminal and issue the command: set | grep SHELL
and let us know what your default shell is.
See this link on how to change it:
http://lifehacker.com/363070/change-leopards-login-shell
You need to restart hugin.
Harry
phar...@gmail.com
> @Steve:
> Can you open a terminal and issue the command: set | grep SHELL
> and let us know what your default shell is.
Sure. Here is the info:
SHELL=/bin/bash
SHELLOPTS=braceexpand:emacs:hashall:histexpand:history:interactive-comments:monitor
+++
> See this link on how to change it:
> http://lifehacker.com/363070/change-leopards-login-shell
>
> You need to restart hugin.
I do not think I would want to change this shell, would I? If so, why?
Steve
Harry van der Wolf
> On Wed, Jan 19, 2011 at 5:00 PM, Harry van der Wolf <hvd...@gmail.com> wrote:
>
>> @Steve:
>> Can you open a terminal and issue the command: set | grep SHELL
>> and let us know what your default shell is.
>
> Sure. Here is the info:
>
> SHELL=/bin/bash
> SHELLOPTS=braceexpand:emacs:hashall:histexpand:history:interactive-comments:monitor
> +++
>
It is already bash as I expected.
>
>> See this link on how to change it:
>> http://lifehacker.com/363070/change-leopards-login-shell
>>
>> You need to restart hugin.
>
> I do not think I would want to change this shell, would I? If so, why?
>
> Steve
>
No, that was only worth to try if your default shell wasn't bsh.
Harry
David Haberthür
>> If one of these tests are successful, the echo utility may be the culprit.
>
> Sir, you are a scholar, and I thank you. I downloaded the Macintosh
> "ptbatcher" GUI having not previously needed it or having ever used
> it. I loaded my .pto file into the batch processor, and voila,
> obtained a fine stitched pano output image. Your above theory seems
> to be quite correct, and because I was thinking the problem was
> related to a specific OS version, we appear to both be vindicated.
> myself with my suspicion and yourself with your solution.
Last October one version of hugin wasn't able to stitch for me, I only could get a successful stitch using PTBatcher [1]. Maybe your problems are somehow related to this...
Cheers, Habi
[1]: http://is.gd/6kSFf8
phar...@gmail.com
<david.ha...@gmail.com> wrote:
> Last October one version of hugin wasn't able to stitch for me, I only could get a successful stitch using PTBatcher [1]. Maybe your problems are somehow related to this...
>
> Cheers, Habi
>
> [1]: http://is.gd/6kSFf8
The indicated link appears to relate to a problem that Hugin had, or
has, with locating the automatic control points creation routine.
That can occur in the most recent Hugin releases if a previous Hugin
preferences file is installed in the users Library/Preferences folder.
Similar control points failures can occur in any part of the path in
which the Hugin application resides contains any blank spaces in any
of the path names.
Steve
T. Modes
> > Sure. Here is the info:
>
> > SHELL=/bin/bash
> > SHELLOPTS=braceexpand:emacs:hashall:histexpand:history:interactive-comments:monitor
> > +++
>
> It is already bash as I expected.
different shells linked to sh in different mac versions.
Gnu make seems to have a bug with the shell variable, as I have see
already in windows.
Even when setting SHELL=cmd.exe in the makefile an other shell
(sh.exe) is used if sh.exe found in the path.
Also in a unix shell (tested in ubuntu) the SHELL variable of the
shell is not used by gnu make.
You need a file test_make with following content:
all:
@echo ${SHELL}
(the second line have to start with a tab and no white spaces)
Then run the following commands:
$ set | grep SHELL
SHELLOPTS=braceexpand:emacs:hashall:histexpand:history:interactive-
comments:monitor
/bin/sh
Thomas
Rogier Wolff
On Wed, Jan 19, 2011 at 06:46:54PM +0100, Stefan Peter wrote:
> This error message has been emitted by gnu make. Now, the error message
> itself seems to originate from echo, a small utility you find as
> /bin/echo in most unix systems.
Or as a builtin in most shells. As make calls the shell for shell
expansions, it's likely that actually the shell interprets and
executes it (if your /bin/sh is advanced enough to have the echo
command builtin. It's an optional performance enhancement, as
/bin/echo works just as well!)
The error is explained in the write system call manual page:
EBADF fd is not a valid file descriptor or is not open for writing.
So standard output apparently isn't connected anywhere. (but as the
error message DOES come through, the stderr IS!!!)
> Inspecting the <panoname>.pto.mk generated by hugin shows that echo is
> used to provide feedback concerning the progress and eventual errors.
> When using the "Stitch now" button in hugin, a window is opened that
> will be used to display these messages.
> The sole purpose of this echo utility is to display text in a console.
> Could it be possible that, probably only this one special version from
> mac os 10.5.4 has a problem emitting text not to a physical console, but
> a wx console widget (or whatever it is called)?
>
> Some tests may clarify this
> o Try to send your project to the batch processor (I hope this
> does exist in the mac version of hugin, too). Make sure
> you have disabled the "Verbose output" option
> o Open a shell, change to the project directory, and use
> "make -f <projectname>.pto.mk"
> to start the stitching
These are sensible tests. When that works, it is increasingly likely
that the hugin gui program is doing something wrong with setting up
the environment for executing make. I've just spent ten minutes trying
to search for where this happens, but couldn't find it. I expect that
a "pipe" or "dup" call is failing. UPDATE: Ok found it by searching
for the "pipe" call...
It seems to be:
src/hugin_base/makefilelib/test_util.cpp
(which is unlogical because it isn't in any test-code anymore, and I
think this is the actual code used, because I can't find any other
pipe calls.
Anyway, on first inspection I'd say that the code looks good. On
the other hand, code like:
if(dup2(fdmakein[0], 0) == -1 || dup2(fdmakeout[1], 1) == -1 || dup2(fdmakeerr[1], 2) == -1) {
std::cerr << "Failed to switch std stream" << std::endl;
exit(-1);
}
should be rewritten as:
stdinfd = dup2 (fdmakein[0], 0);
if (stdinfd != 0) {
// can't dup2 stdinfd...
}
...
so that we'll find where things go wrong. On the other hand, the hint
is that nothing DOES go wrong, because already in the original code
the obvious errors should be caught.
Adding some debug code in this file will also help finding the
culprit....
(the "echo" command per-se will probably not be the culprit. The
echo command is something as simple as:
int main (int argc, char **argv)
{
int i;
for (i=0;i<argc;i++)
printf ("%s%s", i?" ":"", argv[i]);
exit (0);
}
Not much can go wrong there... The echo command is reporting that
there is something wrong with its stdout (1) file descriptor. Possibly
the reader on the pipe has been closed or something. (not likely the
error code should be EPIPE and not EBADF)... )
Roger.
--
** R.E....@BitWizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 **
** Delftechpark 26 2628 XH Delft, The Netherlands. KVK: 27239233 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
Q: It doesn't work. A: Look buddy, doesn't work is an ambiguous statement.
Does it sit on the couch all day? Is it unemployed? Please be specific!
Define 'it' and what it isn't doing. --------- Adapted from lxrbot FAQ
Florian Achleitner
As I wrote it last summer, I can probably help you a little with the
makefilelib.
Generally it seams that the problem with echo and write() occurs when
executing the makefile with make, not during its creation with the
makefilelib.
On Fr, 2011-01-21 at 13:06 +0100, Rogier Wolff wrote:
> The error is explained in the write system call manual page:
>
> EBADF fd is not a valid file descriptor or is not open for writing.
>
> So standard output apparently isn't connected anywhere. (but as the
> error message DOES come through, the stderr IS!!!)
The three standard file descriptors are inherited from the parent so
they don't need to be set explicitly. So maybe it's done nowhere.
> > o Open a shell, change to the project directory, and use
> > "make -f <projectname>.pto.mk"
> > to start the stitching
>
Does it work directly on a shell?
> It seems to be:
>
> src/hugin_base/makefilelib/test_util.cpp
>
> (which is unlogical because it isn't in any test-code anymore, and I
> think this is the actual code used, because I can't find any other
> pipe calls.
> Anyway, on first inspection I'd say that the code looks good. On
> the other hand, code like:
>
>
> if(dup2(fdmakein[0], 0) == -1 || dup2(fdmakeout[1], 1) == -1 || dup2(fdmakeerr[1], 2) == -1) {
> std::cerr << "Failed to switch std stream" << std::endl;
> exit(-1);
> }
This was for development testing only and isn't built unless you
explicitly enable it with a cmake flags, and then isn't run unless you
start one of the dev-testers.
It connects the forked make process to the streams of the tester to
speed up the test, bypassing the creation of a makefile.
There is no connection to the problem you discuss here.
>
> should be rewritten as:
>
> stdinfd = dup2 (fdmakein[0], 0);
> if (stdinfd != 0) {
> // can't dup2 stdinfd...
> }
> ...
The line above normally never fails .. so no need.
--
Flo