cpfind with --fulscale fails to find CPs

Bug #729720 reported by KFJ
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Hugin
Fix Released
Undecided
Unassigned

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

tmodes (tmodes)
Changed in hugin:
milestone: none → 2011.0rc1
status: New → Fix Committed
Revision history for this message
KFJ (kfj) wrote :

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

Yuv (yuv)
Changed in hugin:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.