← Back to team overview

hugin-devs team mailing list archive

[Bug 729720] Re: cpfind with --fulscale fails to find CPs

 

With the fix, cpfind now finds control points with --fullscale. But the
behaviour is still not right. What I found first is that there's
sometimes a discrepancy between cpfind's console output and the number
of CPs it actually finds. I ran a two-image panorama I already had with
--fullscale from the command line, using no other parameters. The
console output stated that cpfind had found 24 matches:

--- Find matches ---
i0 <> i1 : Found 24 matches

But when I opened the resulting pto, there were 217 CPs in it!

Next I tried the same without --fullscale. Surprisingly enough, the
console output now said it had found 25 matches, and the output pto
contained 218 CPs. Though I had anticipated a difference in the number
of CPs found, trying the same images with panomatic produced identical
results with or without --fullscale for the particular pair of images I
was using - therefore the operation of the program is probably correct.

I had used a pto file for the test which already had CPs. If I called
cpfind from the command line, the resulting pto would contain the 217
CPs. When I called cpfind with hugin, 218 CPs were added. But when I
deleted all CPs from the original pto and the called cpfind, only the
number of CPs printed in the console output were added. So cpfind seemed
to behave differently, depending on whether the input pto has CPs
already or not.

Next I set up the project from scratch, with the same two images. Now
when I ran cpfind, it would add 24-25 CPs. Then I ran apsc with large
--maxdim value, resulting in some 2000 CPS. When I now ran cpfind (with
--fullscale), it found over 1600 CPs! When I proceeded to delete all the
CPs and ran it again, it only produced 24 again. When I finally ran it
on the pto with the 24 freshly-generated CPS, it found nearly 1800. Then
I deleted all but 250 CPs and ran cpfind again - it added some 140 new
points. What is going on? I can't really discern a pattern, apart from
the fact that cpfind seems to find wildly varying numbers of CPs, and I
can't quite figure out what triggers the behaviour. The images are the
same all the time, but the number of CPs varied between 24 and nearly
2000.

One way to provoke the behaviour seems to detect lots of CPS first with
apsc and a large maxdim value. Subsequent calls to cpfind found the same
order of magnitude of CPs, as if cpfind tried to come up with a similar
number of CPS it's colleague had found. Is it possible that the CPs from
the input somehow seep into the output, being mixed up with the newly
found CPs? Even when using only cpfind and starting at zero, calling it
several times tends to produce more CPs with every call. But with lots
of CPs from another detector already present, the numbers seem to
skyrocket.

Kay

-- 
You received this bug notification because you are a member of Hugin
Developers, which is subscribed to Hugin.
https://bugs.launchpad.net/bugs/729720

Title:
  cpfind with --fulscale fails to find CPs

Status in Hugin - Panorama Tools GUI:
  Fix Committed

Bug description:
  Today I was running cpfind from the command line with some test images. To get as many CPs as possible, I added --fullscale to the command line, but instead of getting more I got no CPs at all. I tried from hugin with a pto I use for testing, and, lo and behold, cpfind, when run with --fullscale, only found 10 CPs for two unconnected images but none for the others. When I removed the --fullscale, it performed normally and found CPs for all overlapping images.
  I found this behaviour with hugin Pre-Release 2011.1.0.f3a428981466 (cpfind the same build) self-built on Kubuntu 10.10
  Kay



References