Version-dependent control point detection problems

[Greg 'groggy' Lehey]

I've just upgraded my FreeBSD system from 32 bit to 64 bits, and I'm
seeing some strange problems. I've compared the following versions:

(Old) Pre-Release 2011.3.0.478a71d71f90 on FreeBSD i386 (32 bits)
(New) 2011.4.0.cf9be9344356 on FreeBSD amd64 (64 bits)

I used identically the same images as input and found the following
differences:

- panomatic (my previous control point detector of choice) comes up
with really bad matches. On the 32 bit version I got 581 control
points, a mean error of 1.8 pixels and a maximum error of 5.4
pixels. On amd64 I got a mean error of 6.0 and a maximum error of
373.0 pixels. I rebuilt panomatic (proved to be the same version)
and got 5.1 and 243.2.

- nona crashes at random with a bus error:

nona -z LZW -r ldr -m TIFF_m -o 00-26 -i 2 /var/tmp/huginpto_QTZdj0
nona -z LZW -r ldr -m TIFF_m -o 00-26 -i 3 /var/tmp/huginpto_QTZdj0
nona -z LZW -r ldr -m TIFF_m -o 00-26 -i 4 /var/tmp/huginpto_QTZdj0
gmake: *** [00-260004.tif] Bus error: 10 (core dumped)

This doesn't happen in the same place every time. I've been able to
get all 27 images to stitch by repeating the invocation from a
shell.

- I can't get cpfind to work. I suspect I might have a path error,
but the align window closes before I can read the error message. If
anybody can tell me how to get hugin to store the log files
somewhere where I can find them later, I'd be grateful.

I'm still playing around with the software to see what's going on, but
if anybody has any suggestions, or if this seems familiar, I'd be
grateful for feedback.

Greg
--
Sent from my desktop computer.
Finger gr...@FreeBSD.org for PGP public key.
See complete headers for address and phone numbers.
This message is digitally signed. If your Microsoft MUA reports
problems, please read http://tinyurl.com/broken-mua

[Tduell]

Hello Greg,

On Jul 6, 2:42 pm, Greg 'groggy' Lehey <groog...@gmail.com> wrote:
[snip]

> - I can't get cpfind to work.  I suspect I might have a path error,
>   but the align window closes before I can read the error message.  If
>   anybody can tell me how to get hugin to store the log files
>   somewhere where I can find them later, I'd be grateful.

If you haven't already done so, try running cpfind from the
commandline in a terminal. That may allow you capture any messages.
The problem with cpfind may be related to threads. Try using --ncores
to set the number to 1 and see what happens.
Do you build your versions of hugin yourself or download?

Let's hear how you get on.

Cheers,
Terry

[Gnome Nomad]

Hmm, I have same version on 64-bit Debian Sid and don't get crashes in
nona and CPFind works. Don't use panomatic. Could you put your images up
somewhere so I can try them?

Gnome Nomad
gnome...@gmail.com
wandering the landscape of god
http://www.clanjones.org/david/
http://dancing-treefrog.deviantart.com/
http://www.cafepress.com/otherend/

[Harry van der Wolf]

2012/7/6 Greg 'groggy' Lehey <groo...@gmail.com>

- I can't get cpfind to work.  I suspect I might have a path error,
  but the align window closes before I can read the error message.  If
  anybody can tell me how to get hugin to store the log files
  somewhere where I can find them later, I'd be grateful.

 

I think something is wrong in both panomatic and cpfind (as cpfind is partly based on panomatic) in the 64bit includes/coding. I have been working on/with cpfind since the very first builds (when it was still called panomatic-lib by Pablo), be it from builder perspective and not programmer perspective.

64bit panomatic had some issues on OSX in the beginning. 64bit cpfind has been segfaulting on OSX from the very first beginning and still doesn't work as 64bit (I mentioned it several times but I must admit I only recently filed a bug).

 

Noting that OSX is a freeBSD derived OS might mean that cpfind on both freebsd and OSX suffers from the same issue.

This might also clarify why it does work on (all?) Linuxes as Linux is definitely not {net, free, open}BSD derived.

 

I filed a bug ticket for this: https://bugs.launchpad.net/hugin/+bug/1011111

 

 

Harry

[Greg 'groggy' Lehey]

On Friday, 6 July 2012 at 9:22:47 +0200, Harry van der Wolf wrote:
> 2012/7/6 Greg 'groggy' Lehey <groo...@gmail.com>
>
>> - I can't get cpfind to work. I suspect I might have a path error,
>> but the align window closes before I can read the error message. If
>> anybody can tell me how to get hugin to store the log files
>> somewhere where I can find them later, I'd be grateful.

It wasn't a path error. It did start and then crashed. I'm busy with
other stuff, but I intend to try again with cpfind as soon as I have
time. Any ideas on saving the log file?

> I think something is wrong in both panomatic and cpfind (as cpfind is
> partly based on panomatic) in the 64bit includes/coding. I have been
> working on/with cpfind since the very first builds (when it was still
> called panomatic-lib by Pablo), be it from builder perspective and not
> programmer perspective.
> 64bit panomatic had some issues on OSX in the beginning. 64bit cpfind has
> been segfaulting on OSX from the very first beginning and still doesn't
> work as 64bit (I mentioned it several times but I must admit I only
> recently filed a bug).

That's certainly interesting. When I get my other problems under
control, I may take a closer look at the code.

> Noting that OSX is a freeBSD derived OS might mean that cpfind on both
> freebsd and OSX suffers from the same issue.
> This might also clarify why it does work on (all?) Linuxes as Linux is
> definitely not {net, free, open}BSD derived.

I don't think this is the case; more good luck, I'd think. I'd assert
that the issue is in the executables and not in the kernel, though I'd
be happy to be proven wrong. mmap() springs to mind, but I don't know
whether it's used or not.

> I filed a bug ticket for this:
> https://bugs.launchpad.net/hugin/+bug/1011111

Possibly a bit premature, unless you're referring to the issues with
Mac OS X.

I've run into another problem which may not be due to Hugin: the move
tab in the fast panorama preview doesn't work. At least, I can't move
anything. Everything else works. The problem is that it doesn't work
when I put the old version on the display either, so it looks like
something to do with the X server rather than Hugin. If this
particular area rings a bell (like using specific functionality), I'd
be interested to hear of it.

[arclance]

On Fri, 2012-07-06 at 18:58 +1000, Greg 'groggy' Lehey wrote:
> I've run into another problem which may not be due to Hugin: the move
> tab in the fast panorama preview doesn't work. At least, I can't move
> anything. Everything else works. The problem is that it doesn't work
> when I put the old version on the display either, so it looks like
> something to do with the X server rather than Hugin. If this
> particular area rings a bell (like using specific functionality), I'd
> be interested to hear of it.

I have the same problem in 64-bit Debian, left clicking in the image
area of the move tab of the fast preview does nothing.

There is a least one bug report about it
https://bugs.launchpad.net/hugin/+bug/797370
but it is a "Won't Fix" bug.

I am able to work around the bug by middle clicking and then left
clicking.

[Tduell]

Greg,
I re-ran a build of Hugin and then did a snoop through the all the log
and there are a number of warnings related to cpfind and zthread...but
then there are lots of warnings about all sorts of things.
I had previously found a reference to a cpfind failure (on Win7 I
think) but didn't keep the reference. That seemed to relate to
threading and the workaround was to run cpfind with '--ncores 1'. If
you haven't tried that it might be a worthwhile test.
Also, if the threading issue is a real one, maybe running with
valgrind, looking for threading problems might turn up some clues.

Cheers,
Terry

[Gnome Nomad]

Hmmm, cpfind works here with "--ncores 4" on my 64-bit Athlon II x4,
running Linux. Maybe threading problem is more specific to Windows?

Anyway, Linux version prior to what I have now automatically used all
available cores without me specifying the number to use. Version I
currently have (from Debian Sid) required me to specify the number of
cores, or it used only a single core.

[Tduell]

> Hmmm, cpfind works here with "--ncores 4" on my 64-bit Athlon II x4,
> running Linux. Maybe threading problem is more specific to Windows?

Yes, I haven't seen this problem reported on Linux, but as the
problems Greg and Harry refer to are not on Linux or Windows, it may
still be a worthwhile avenue of investigation on freeBSD and OSX...at
least to be able to rule it out.

> Anyway, Linux version prior to what I have now automatically used all
> available cores without me specifying the number to use. Version I
> currently have (from Debian Sid) required me to specify the number of
> cores, or it used only a single core.

I just ran a test on a build of the current source (on Fedora 17
x86_64) and it automatically uses available cores.

Cheers,
Terry

[Gnome Nomad]

On 07/07/2012 02:10 PM, Tduell wrote:

>> Hmmm, cpfind works here with "--ncores 4" on my 64-bit Athlon II x4,
>> running Linux. Maybe threading problem is more specific to Windows?
>
> Yes, I haven't seen this problem reported on Linux, but as the
> problems Greg and Harry refer to are not on Linux or Windows, it may
> still be a worthwhile avenue of investigation on freeBSD and OSX...at
> least to be able to rule it out.

Sorry, I seemed to think this was on a Windows system.

>> Anyway, Linux version prior to what I have now automatically used all
>> available cores without me specifying the number to use. Version I
>> currently have (from Debian Sid) required me to specify the number of
>> cores, or it used only a single core.
>
> I just ran a test on a build of the current source (on Fedora 17
> x86_64) and it automatically uses available cores.

Current Debian Sid only has 2011.4.0.cf9be9344356.

[Greg 'groggy' Lehey]

Thanks. This helps a lot.

[Greg 'groggy' Lehey]

On Friday, 6 July 2012 at 19:43:07 -0700, Tduell wrote:
>
> Greg,
> I re-ran a build of Hugin and then did a snoop through the all the log
> and there are a number of warnings related to cpfind and zthread...but
> then there are lots of warnings about all sorts of things.
> I had previously found a reference to a cpfind failure (on Win7 I
> think) but didn't keep the reference. That seemed to relate to
> threading and the workaround was to run cpfind with '--ncores 1'. If
> you haven't tried that it might be a worthwhile test.

That turned out not to be the issue. Brief version: I've installed
version Pre-Release 2011.5.0.cf3324753b7f and I have cpfind working
now, at least some of the time. The problem was that the parameters
to cpfind are different from those for panomatic, and not only did I
not know that, I couldn't find anywhere to set them. I seem to
remember that you could set this kind of thing in earlier versions of
Hugin, but I can't find anything in the current version.

I'm still investigating things, and there's a lot more to say. It
seems that both panomatic and cpfind will create control points on a
single image, and not even correctly. One example is at
http://www.lemis.com/grog/diary-jul2012.php#hugin-bug , but I've seen
it with cpfind as well.

More later, probably tomorrow.

[Terry Duell]

Hello Greg,

On Sun, 08 Jul 2012 15:11:36 +1000, Greg 'groggy' Lehey
<groo...@gmail.com> wrote:

[snip]

> That turned out not to be the issue. Brief version: I've installed
> version Pre-Release 2011.5.0.cf3324753b7f

OK, without checking, that looks like the latest default branch code.

> and I have cpfind working
> now, at least some of the time. The problem was that the parameters
> to cpfind are different from those for panomatic, and not only did I
> not know that, I couldn't find anywhere to set them. I seem to
> remember that you could set this kind of thing in earlier versions of
> Hugin, but I can't find anything in the current version.

Do you mean you can't set cpfind parameters in 2011.5.0.cf3324753b7f?
I am running a build of the latest gui_overhaul branch, and editing CP
detector parameters is OK here. My first guess is that this part of the
code would probably be unchanged.
In the main window, use file > preferences > control point detectors,
select your detector and then select 'edit' to play with the parameters.

> I'm still investigating things, and there's a lot more to say. It
> seems that both panomatic and cpfind will create control points on a
> single image, and not even correctly. One example is at
> http://www.lemis.com/grog/diary-jul2012.php#hugin-bug , but I've seen
> it with cpfind as well.

A couple of quick tests here with only one image and cpfind doesn't find
any control points.


Cheers,
--
Regards,
Terry Duell

[Greg 'groggy' Lehey]

On Sunday, 8 July 2012 at 16:08:28 +1000, Terry Duell wrote:
> Hello Greg,
>
> On Sun, 08 Jul 2012 15:11:36 +1000, Greg 'groggy' Lehey
> <groo...@gmail.com> wrote:
>
>> That turned out not to be the issue. Brief version: I've installed
>> version Pre-Release 2011.5.0.cf3324753b7f
>
> OK, without checking, that looks like the latest default branch code.

Yes, I checked it out this morning.

>> and I have cpfind working now, at least some of the time. The
>> problem was that the parameters to cpfind are different from those
>> for panomatic, and not only did I not know that, I couldn't find
>> anywhere to set them. I seem to remember that you could set this
>> kind of thing in earlier versions of Hugin, but I can't find
>> anything in the current version.
>
> Do you mean you can't set cpfind parameters in 2011.5.0.cf3324753b7f?
> I am running a build of the latest gui_overhaul branch, and editing CP
> detector parameters is OK here. My first guess is that this part of the
> code would probably be unchanged.
> In the main window, use file > preferences > control point detectors,
> select your detector and then select 'edit' to play with the
> parameters.

Ah, thanks. Yes, that works.

>> I'm still investigating things, and there's a lot more to say. It
>> seems that both panomatic and cpfind will create control points on a
>> single image, and not even correctly. One example is at
>> http://www.lemis.com/grog/diary-jul2012.php#hugin-bug , but I've seen
>> it with cpfind as well.
>
> A couple of quick tests here with only one image and cpfind doesn't find
> any control points.

It's not that simple. 32 bit cpfind doesn't find them here either,
and sometimes the 64 bit version doesn't either. The images for the
panorama in the diary entry
(http://www.lemis.com/grog/diary-jul2012.php#hugin-bug) are at
http://www.lemis.com/grog/Photos/20120706/tiny/house-looking-s-0.jpeg
to
http://www.lemis.com/grog/Photos/20120706/tiny/house-looking-s-3.jpeg
if anybody's interested in trying them. But I doubt it is repeatable
elsewhere.

One thing that occurs to me is that maybe the bug is compiler version
sensitive. I used gcc 4.2 to build this Hugin. I also have gcc 4.6.4
and gcc 4.7.2. Does anybody think that might help?

[Terry Duell]

Hello Greg,

On Sun, 08 Jul 2012 16:46:07 +1000, Greg 'groggy' Lehey
<groo...@gmail.com> wrote:

[snip]

> It's not that simple. 32 bit cpfind doesn't find them here either,
> and sometimes the 64 bit version doesn't either. The images for the
> panorama in the diary entry
> (http://www.lemis.com/grog/diary-jul2012.php#hugin-bug) are at
> http://www.lemis.com/grog/Photos/20120706/tiny/house-looking-s-0.jpeg
> to
> http://www.lemis.com/grog/Photos/20120706/tiny/house-looking-s-3.jpeg
> if anybody's interested in trying them. But I doubt it is repeatable
> elsewhere.

Here, (current gui_default branch, 64 bit, build with gcc-4.7.0-5) cpfind
only manages to find CPs on pics xxx-1 and xxx-2. Maybe that is a function
of the image resolution.
Were you working with the images referred to above, or with higher res
versions?

> One thing that occurs to me is that maybe the bug is compiler version
> sensitive. I used gcc 4.2 to build this Hugin. I also have gcc 4.6.4
> and gcc 4.7.2. Does anybody think that might help?

I really don't know. Worth a try building with a later version of gcc.

[Greg 'groggy' Lehey]

On Monday, 9 July 2012 at 15:49:29 +1000, Terry Duell wrote:
> Hello Greg,
>
> On Sun, 08 Jul 2012 16:46:07 +1000, Greg 'groggy' Lehey
> <groo...@gmail.com> wrote:
>
>> It's not that simple. 32 bit cpfind doesn't find them here either,
>> and sometimes the 64 bit version doesn't either. The images for
>> the panorama in the diary entry
>> (http://www.lemis.com/grog/diary-jul2012.php#hugin-bug) are at
>> http://www.lemis.com/grog/Photos/20120706/tiny/house-looking-s-0.jpeg
>> to
>> http://www.lemis.com/grog/Photos/20120706/tiny/house-looking-s-3.jpeg
>> if anybody's interested in trying them. But I doubt it is
>> repeatable elsewhere.
>
> Here, (current gui_default branch, 64 bit, build with gcc-4.7.0-5)
> cpfind only manages to find CPs on pics xxx-1 and xxx-2. Maybe that
> is a function of the image resolution. Were you working with the
> images referred to above, or with higher res versions?

Ah, sorry. There are three different resolutions of image there; I
accidentally gave the smallest (300x225). FWIW, I didn't get any
control points at all with the images I mentioned, but there are
full-sized versions at
http://www.lemis.com/grog/Photos/20120706/big/house-looking-s-0.jpeg
to
http://www.lemis.com/grog/Photos/20120706/big/house-looking-s-3.jpeg ,
and that should work fine. But I'd be surprised if you got the same
results. What system and word size are you using?

I've written up yesterday's experiments in my diary at
http://www.lemis.com/grog/diary-jul2012.php#hugin , including images
of how far off the control points are.

I've done a lot more experimentation today, including running the i386
versions of cpfind and panomatic under the amd64 version of Hugin. In
the case of the images we're talking about here, panomatic-i386 does
much better and doesn't create any control points on the same image.
But with another panorama, the problem persists, suggesting that it's
not (only) in the control point detectors.

[Felix Hagemann]

On 8 July 2012 07:11, Greg 'groggy' Lehey wrote:
>
> I'm still investigating things, and there's a lot more to say. It
> seems that both panomatic and cpfind will create control points on a
> single image, and not even correctly. One example is at
> http://www.lemis.com/grog/diary-jul2012.php#hugin-bug , but I've seen
> it with cpfind as well.

Just a quick heads up in case you didn't notice: Those are vertical
line control points and they look pretty good actually. This is a
recently added feature (linefind) which adds vertical line control
points automatically and has nothing to do with either cpfind or
panomatic.

Felix

[Greg 'groggy' Lehey]

Thanks for that. Yes, I noticed that linefind ran, but I didn't
understand the connection with the points. Maybe that's where the bug
is. The fact remains that things worked well with the old version and
very badly with the new, but now I have something else to follow up
on.

[arclance]

On Sun, 2012-07-08 at 14:06 +1000, Greg 'groggy' Lehey wrote:
> On Friday, 6 July 2012 at 20:27:58 -0400, arclance wrote:
> > I am able to work around the bug by middle clicking and then left
> > clicking.
>
> Thanks. This helps a lot.
>
> Greg

Your welcome, I am glad that work around also works for you.

I would still like to know why the left click does not work so if the
problem is really due to the window manager it can be fixed more easily.

There is an open bug report about extra events produced by left clicks
in my window manger (Fluxbox) but it is over year old.
https://sourceforge.net/tracker/?func=detail&aid=3164835&group_id=35398&atid=413960

[Terry Duell]

Hello Greg,

On Mon, 09 Jul 2012 17:47:57 +1000, Greg 'groggy' Lehey
<groo...@gmail.com> wrote:

> On Monday, 9 July 2012 at 15:49:29 +1000, Terry Duell wrote:

[snip]

>> Here, (current gui_default branch, 64 bit, build with gcc-4.7.0-5)
>> cpfind only manages to find CPs on pics xxx-1 and xxx-2. Maybe that
>> is a function of the image resolution. Were you working with the
>> images referred to above, or with higher res versions

> Ah, sorry. There are three different resolutions of image there; I
> accidentally gave the smallest (300x225). FWIW, I didn't get any
> control points at all with the images I mentioned, but there are
> full-sized versions at
> http://www.lemis.com/grog/Photos/20120706/big/house-looking-s-0.jpeg
> to
> http://www.lemis.com/grog/Photos/20120706/big/house-looking-s-3.jpeg ,
> and that should work fine. But I'd be surprised if you got the same
> results. What system and word size are you using?

OK, these images work much better.
Here (current gui_default branch, Fedora 17 x86_64, build with gcc-4.7.0-5)
cpfind finds 5 CPs in 0-0, 2-2, and 3-3, but these are not in error, they
are being used to detect vertical lines. This may be what you are seeing.
Here, using the gui_overhaul branch version, this happens if 'detect
vertical lines' is set in 'preferences > assistant', and the assistant is
used to align, but doesn't happen if the CPs are created using 'Create
Control Points' in the Photos tab.
The set of images stitch up OK.

Hope this helps with this problem.

[Greg 'groggy' Lehey]

On Monday, 9 July 2012 at 18:58:13 -0400, arclance wrote:
> On Sun, 2012-07-08 at 14:06 +1000, Greg 'groggy' Lehey wrote:
>> On Friday, 6 July 2012 at 20:27:58 -0400, arclance wrote:
>>> I am able to work around the bug by middle clicking and then left
>>> clicking.
>>
>> Thanks. This helps a lot.
>

> Your welcome, I am glad that work around also works for you.
>
> I would still like to know why the left click does not work so if
> the problem is really due to the window manager it can be fixed more
> easily.

It's definitely due to the window manager (fvwm2) in my case. I tried
stopping the window manager; then the move function worked normally.
After restarting the window manager, it no longer worked.

I've now tried running the 32 bit version of fvwm2, and that works.
So it's very clearly a problem with the 64 bit version.

> There is an open bug report about extra events produced by left
> clicks in my window manger (Fluxbox) but it is over year old.
> https://sourceforge.net/tracker/?func=detail&aid=3164835&group_id=35398&atid=413960

This is pretty much what I see, except that it happens with all
buttons. The sequence is:

LeaveNotify event, serial 35, synthetic NO, window 0x9c00004,
EnterNotify event, serial 35, synthetic NO, window 0x9c00004,
KeymapNotify event, serial 35, synthetic NO, window 0x0,
ButtonPress event, serial 35, synthetic NO, window 0x9c00004,
ButtonRelease event, serial 35, synthetic NO, window 0x9c00004,

With the 32 bit version, I only get the last two, as you'd expect.

[Greg 'groggy' Lehey]

On Tuesday, 10 July 2012 at 9:10:53 +1000, Terry Duell wrote:
> On Mon, 09 Jul 2012 17:47:57 +1000, Greg 'groggy' Lehey <groo...@gmail.com> wrote:
>
>> Ah, sorry. There are three different resolutions of image there; I
>> accidentally gave the smallest (300x225). FWIW, I didn't get any
>> control points at all with the images I mentioned, but there are
>> full-sized versions at
>> http://www.lemis.com/grog/Photos/20120706/big/house-looking-s-0.jpeg
>> to
>> http://www.lemis.com/grog/Photos/20120706/big/house-looking-s-3.jpeg ,
>> and that should work fine. But I'd be surprised if you got the same
>> results. What system and word size are you using?
>
> OK, these images work much better.
> Here (current gui_default branch, Fedora 17 x86_64, build with gcc-4.7.0-5)
> cpfind finds 5 CPs in 0-0, 2-2, and 3-3, but these are not in error, they
> are being used to detect vertical lines. This may be what you are
> seeing.

Yes, it seems so.

> Here, using the gui_overhaul branch version, this happens if 'detect
> vertical lines' is set in 'preferences > assistant', and the assistant is
> used to align, but doesn't happen if the CPs are created using 'Create
> Control Points' in the Photos tab.
> The set of images stitch up OK.
>
> Hope this helps with this problem.

It certainly helps me localize it. And yes, it seems that that's the
problem. It's interesting that the Assistant takes the length of
these control points as an error. But I have been able to build
normally by disabling the line detection. I'll report more if I have
something useful to say. There's more information in my diary for
yesterday, now a bit out of date.