iterations of cpfind gives back different number of points (matches)

[André Mende]

Hello,

The following effect i have noticed.
If i use cpfind to find tie-points between four images (--linearalign)
there a deviations between the matching results (different number of
tie-points between image[2] and [3]).

first time:
16 matches

second time:
0 matches

third time:
24 matches

etc...
This calculation was done on Windows XP Professional 32 Bit (Hugin 4.0
32bit).
After that i calculated the same images on an other pc with Windows 7
Professional 64 Bit (Hugin 4.0 64bit).
I this case the calculation of different times gives back a constant
number of tie-points!

What could be the reason for this effect? I thought the cpfind-
algorithm has a static approach how to find tie-points without a
result variablity....

Thanks again and i wish you all a nice day.

Best regards, Andre Mende

[André Mende]

I have tested this effect with other computers. The result is the
same. The 64-bit version of hugin find (constant) more tie-points than
the 32-bit version.

If some have an idea, please give a feedback.

Thanks, André

[Naked Robot]

I have noticed this also.

Many panos give a consistent same result, but some give a different result (and different CP) each time. It is very strange.

Can anyone explain why CPFind would give random/different results each time it is run?

[Naked Robot]

It was this set of images http://dl.dropbox.com/u/14314213/20120115161554_panorama_1326722096.zip that gave a really different result each time.

[Gnome Nomad]

And how come I can take a project all the way through finding control
points, optimizing, etc, save it - then open it the very next day and
have Hugin tell me "Control points have changed, images need realignment"?

--
Gnome Nomad
gnome...@gmail.com
wandering the landscape of god
http://www.cafepress.com/otherend/

[Naked Robot]

Please don't hijack this thread.

For me this is a very serious issue. The behavior of cpfind seems to be semi-random.

Is anyone able to explain this?

thank you!

[André Mende]

I can only support the wish of an good explanation of this problem.
Are there any experts who have a solution or an idea?

[Harry van der Wolf]

2012/2/8 André Mende <andre.m...@googlemail.com>

I can only support the wish of an good explanation of this problem.
Are there any experts who have a solution or an idea?

I can't reproduce this at all with a 32bit cpfind on Mac OS X. I did 8 consecutive runs on one set and 4 on another and the results were always exactly the same. The 64bit build still segfaults so I can't test that one.

Then I did the same test on 32 bits Ubuntu 11.10 linux (2 sets now each 4 times): Only one calculation delivered one match less (floating point accuracy?), the rest were also exactly the same.

I tend to think that this is a windows related issue.

Harry

[Bart van Andel]

On Wednesday, February 8, 2012 2:25:51 PM UTC+1, Harry van der Wolf wrote:

Only one calculation delivered one match less (floating point accuracy?)

Floating point accuracy will be exactly the same for consecutive runs (unless your processor is physically broken), so this cannot be the issue.

I haven't looked at the algorithms used (or the source code at all), but if RANSAC (random sampling consensus) is used, the differences can be caused by different seeds for the randomizer. Note that in this case it isn't really a bug, although it may seem strange. RANSAC needs randomization. The results would be the same every time if the "random" values used by RANSAC were more or less static (e.g. same initial seed instead of based on the computer clock) which would solve this apparent issue. But this is a mere guess.

--

Bart

[kfj]

On 10 Feb., 10:09, Bart van Andel <bavanan...@gmail.com> wrote:

> I haven't looked at the algorithms used (or the source code at all), but if
> RANSAC (random sampling consensus) is used, the differences can be caused
> by different seeds for the randomizer. Note that in this case it isn't
> really a bug, although it may seem strange. RANSAC needs randomization. The
> results would be the same every time if the "random" values used by RANSAC
> were more or less static (e.g. same initial seed instead of based on the
> computer clock) which would solve this apparent issue. But this is a mere
> guess.

good guss. a quick look at ransac.h reveals:

// intialize random generator
boost::mt19937 rng;
// start with a different seed every time.
rng.seed(static_cast<unsigned int>(std::time(0)));

I suspected a different random generator state myself, but was too
lazy to check...
If any of the people affected by the 'bug' have compile capability,
they can try and simply seed the rng with, say, 23 and see if the
problem persists

Kay

[Carlos Eduardo G. Carvalho (Cartola)]

Just a thought, but if the reason was that wouldn't the problem occur on all platforms?

Carlos E G Carvalho (Cartola)
http://cartola.org/360

2012/2/10 kfj <_k...@yahoo.com>

--
You received this message because you are subscribed to the Google Groups "Hugin and other free panoramic software" group.
A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ
To post to this group, send email to hugi...@googlegroups.com
To unsubscribe from this group, send email to hugin-ptx+...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx

[Rogier Wolff]

On Fri, Feb 10, 2012 at 09:04:22AM -0200, Carlos Eduardo G. Carvalho (Cartola) wrote:
> > If any of the people affected by the 'bug' have compile capability,
> > they can try and simply seed the rng with, say, 23 and see if the
> > problem persists

I'd say: Don't seed the RNG at all. That way, to the program the
random number generator will still produce "random" results, but the
random numbers will be the same sequence every time the program is
run.

(Seeding with 23 works just as well, don't worry).

For testing/debugging, it might be useful to add an option that
controls the seeding:
default:
--seed=0
(seed with the value zero or don't seed. These are probably the same).

you can seed with a specific value like this:
--seed=<value>

or you can seed with the time:
--seed=time
or with /dev/random:
--seed=random

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! --*
The plan was simple, like my brother-in-law Phil. But unlike
Phil, this plan just might work.

[kfj]

On 10 Feb., 12:27, Rogier Wolff <rew-googlegro...@BitWizard.nl> wrote:

> I'd say: Don't seed the RNG at all. That way, to the program the
> random number generator will still produce "random" results, but the
> random numbers will be the same sequence every time the program is
> run.

Are you sure? Isn't it up to the implementation how to provide the
random numbers? Explicitly seeding it would assure an identical
behaviour, while not seeding it only might produce it.

> (Seeding with 23 works just as well, don't worry).

probably better than 42 ;-)

I wonder if there is a seed value which produces the best control
points, then?

Kay

[Naked Robot]

Sorry, I'm embarrassed. I had been using autopano-sift-c when i got these random results.

I guess my question is the same though but it's not about cpfind :)

[Gnome Nomad]

Might be interesting to run the same tests on the same images using
cpfind, then compare the output with what autopano-sift-c gave you.