Core dump: Assertion `p.first != p.second' failed.

[mardy]

I'm running bundler on a set of photos with no focal length information. I first ran into a problem because the image resolution was too high (5312x3984 pixels) for sift to handle, so I downscaled them all to half their size. Incidentally, if someone has a link to the sift source code, please share it: I want to rebuild it with this limitation lifted, and also make a 64bit version of it.

Anyway, according to FAQ item 1, I first ran the bundler.py script with the --extract-focal parameter to obtain the list.txt file, and there I extended each line with " 0 3187". This is probably not the real focal length, just a quick estimate (I've read that a reasonable estimation for the focal length is max(width, height) * 1.2). Then I ran the bundler.py script again (with no options), so that it could compute the matches, and then I ran bundler list.txt --options_file options.txt and got this:

[OnInit] Running program bundler
Loading images from file 'list.txt'
[BundlerApp::OnInit] Processing options...
[BundlerApp::OnInit] Loading frame...
[BundlerApp::OnInit] Loading images...
[ReadGeometricConstraints] Reading 0 tracks
[ReadGeometricConstraints] Reading tracks took 0.000s
[ReadTrackPairs] Read 0 track pairs
  Avg. proj error [0 projections] = -nan
[BundleAdjust] Error: no good camera pairs found!
[BundleAdjust] Trying a backup approach...
[BundleAdjust] Error: no good camera pairs found!
[BundleAdjust] Picking first two cameras...
[BundleAdjust] Adjusting cameras 0 and 1 (score = 0.000)
[GetJPEGDimensions] File ./image20170205_134820745.jpg: ( 2656 , 1992 )
[GetJPEGDimensions] File ./image20170205_134551277.jpg: ( 2656 , 1992 )
[BaseApp::SetTracks] Setting tracks for image 0...
[BaseApp::SetTracks] Finished in 0.000s
[BaseApp::SetTracks] Setting tracks for image 1...
[BaseApp::SetTracks] Finished in 0.000s
bundler: BaseApp.h:271: std::vector<KeypointMatch>& MatchTable::GetMatchList(MatchIndex): Assertion `p.first != p.second' failed.
Aborted (core dumped)

Could it be because my focal length estimation was way off, or is there some other problem here?
Also, when downscaling the photos, should the focal length be downscaled proportionally, or should itbe left untouched?

[snavely]

Hi Alberto, First, check out libsiftfast <https://sourceforge.net/projects/libsift/files/libsiftfast/>. It is a reimplementation of SIFT that produces nearly identical results (libsiftfast includes a minor bug fix that changes a small percentage of features). As far as I know it doesn't have the same size limitation as the Lowe SIFT binary. Second, when downscaling images, yes, you should also reduce the focal length proportionally. (For instance, if width and height are scaled by 0.5, then focal length also should scale by 0.5.) Third, you are doing the right thing and so I'm not sure why Bundler is complaining. I am not that familiar with the bundler.py script because it was contributed by another person, but I suppose you should first make sure it is not overwriting your modified list.txt file. Second, I would make sure that the match file is not empty -- there is a match subdirectory that gets created that should have a ton of files in it, as well as a file called constrants.txt that should have a lot of information in it. Does anything seem suspicious there? I should really change the code to output a better error message. Noah

On Thu, Feb 9, 2017 at 12:38 AM Alberto Mardegan ***@***.***> wrote: I'm running bundler on a set of photos with no focal length information. I first ran into a problem because the image resolution was too high (5312x3984 pixels) for sift to handle, so I downscaled them all to half their size. *Incidentally, if someone has a link to the sift source code, please share it*: I want to rebuild it with this limitation lifted, and also make a 64bit version of it. Anyway, according to FAQ item 1, I first ran the bundler.py script with the --extract-focal parameter to obtain the list.txt file, and there I extended each line with " 0 3187". This is probably not the real focal length, just a quick estimate (I've read that a reasonable estimation for the focal length is max(width, height) * 1.2). Then I ran the bundler.py script again (with no options), so that it could compute the matches, and then I ran bundler list.txt --options_file options.txt and got this: [OnInit] Running program bundler Loading images from file 'list.txt' [BundlerApp::OnInit] Processing options... [BundlerApp::OnInit] Loading frame... [BundlerApp::OnInit] Loading images... [ReadGeometricConstraints] Reading 0 tracks [ReadGeometricConstraints] Reading tracks took 0.000s [ReadTrackPairs] Read 0 track pairs Avg. proj error [0 projections] = -nan [BundleAdjust] Error: no good camera pairs found! [BundleAdjust] Trying a backup approach... [BundleAdjust] Error: no good camera pairs found! [BundleAdjust] Picking first two cameras... [BundleAdjust] Adjusting cameras 0 and 1 (score = 0.000) [GetJPEGDimensions] File ./image20170205_134820745.jpg: ( 2656 , 1992 ) [GetJPEGDimensions] File ./image20170205_134551277.jpg: ( 2656 , 1992 ) [BaseApp::SetTracks] Setting tracks for image 0... [BaseApp::SetTracks] Finished in 0.000s [BaseApp::SetTracks] Setting tracks for image 1... [BaseApp::SetTracks] Finished in 0.000s bundler: BaseApp.h:271: std::vector<KeypointMatch>& MatchTable::GetMatchList(MatchIndex): Assertion `p.first != p.second' failed. Aborted (core dumped) Could it be because my focal length estimation was way off, or is there some other problem here? Also, when downscaling the photos, should the focal length be downscaled proportionally, or should itbe left untouched? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#46>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABt6q0MBbvfyh7gTTn38J6w_90PKE3mDks5ratBqgaJpZM4L72Fc> .

--

…

------------------------------------------------------------------- Noah Snavely Associate Professor Email: [email protected] Dept. of Computer Science Phone: (607) 255 4280 Cornell University URL : www.cs.cornell.edu/~snavely 307 Gates Hall Ithaca, NY 14853 -------------------------------------------------------------------

[mardy]

Hi Noah, thanks for your reply! So, I rebuilt bundler with siftfast, and adjusted the scripts to use it instead of sift. Now the feature detection works without the need of downscaling the images.

However, I still get the same error when running Bundler. I've ran it from a clean directory (with only the images in), and no matches subdirectory was created (but maybe that's the way the bundler.py script works?); instead, there are these files:

list.txt
matches.corresp.txt
matches.init.txt
matches.prune.txt
matches.ransac.txt
nmatches.corresp.txt
nmatches.prune.txt
nmatches.ransac.txt
options.txt
pairwise_scores.txt

They have data inside, but the matches.corresp.txt is a bit suspicious in that it contains just 1062 empty lines -- no other content at all.
I'm attaching the bundle/out file, which is much bigger than the previous one: bundle.txt

Please let me know if you'd like to have a look at any of the files above, I'll attach them here.

[snavely]

Ah, you are right -- the matches directory thing is something that happens in an experimental version of bundler that runs matching in parallel. The number of matches indicated by your bundler log seem very low. Very few image pairs have more than a few dozen matches. And only 422 tracks are found. What are these images like? It seems like SIFT matching isn't working very well for them, which might explain the error you are seeing (Bundler tries to find a pair of images with >100 matches as the initial seed for the model, and if it can't I believe it falls back to images 0 and 1, which doesn't always actually match.) Noah

On Sun, Feb 12, 2017 at 5:40 AM Alberto Mardegan ***@***.***> wrote: Hi Noah, thanks for your reply! So, I rebuilt bundler with siftfast, and adjusted the scripts to use it instead of sift. Now the feature detection works without the need of downscaling the images. However, I still get the same error when running Bundler. I've ran it from a clean directory (with only the images in), and no matches subdirectory was created (but maybe that's the way the bundler.py script works?); instead, there are these files: list.txt matches.corresp.txt matches.init.txt matches.prune.txt matches.ransac.txt nmatches.corresp.txt nmatches.prune.txt nmatches.ransac.txt options.txt pairwise_scores.txt They have data inside, but the matches.corresp.txt is a bit suspicious in that it contains just 1062 empty lines -- no other content at all. I'm attaching the bundle/out file, which is much bigger than the previous one: bundle.txt <https://github.com/snavely/bundler_sfm/files/769321/bundle.txt> Please let me know if you'd like to have a look at any of the files above, I'll attach them here. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#46 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABt6q6RUsObHOU1M669ZHwgMJhnXXpWzks5rbwvFgaJpZM4L72Fc> .

--

…

------------------------------------------------------------------- Noah Snavely Associate Professor Email: [email protected] Dept. of Computer Science Phone: (607) 255 4280 Cornell University URL : www.cs.cornell.edu/~snavely 307 Gates Hall Ithaca, NY 14853 -------------------------------------------------------------------

[mardy]

I'm using these images:
https://github.com/rperrot/ReconstructionDataSet/tree/master/MirebeauStHilaireStatue

I want to make a comparison among SfM software, so I'm trying the same dataset with bundler, mve, colmap, VisualSfM, openMVG, etc. This dataset seems to work fine with the other programs, so it's probably a matter of giving bundler the right options. Any hints will be very appreciated :-)

[snavely]

I will look into that. One comment about libsiftfast, which I forgot to mention but you may have already figured out -- I believe it outputs features in a slightly different format from Lowe's sift -- I believe libsiftfast gives 2D image coordinates in (x, y) order, whereas Lowe's sift gives them in (y, x) order. Noah

On Sun, Feb 12, 2017 at 11:40 PM Alberto Mardegan ***@***.***> wrote: I'm using these images: https://github.com/rperrot/ReconstructionDataSet/tree/master/MirebeauStHilaireStatue I want to make a comparison among SfM software, so I'm trying the same dataset with bundler, mve, colmap, VisualSfM, openMVG, etc. This dataset seems to work fine with the other programs, so it's probably a matter of giving bundler the right options. Any hints will be very appreciated :-) — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#46 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABt6q-Yn01D8ZJN_w8DJ8bK9k0wxFaBiks5rcAj3gaJpZM4L72Fc> .

--

…

------------------------------------------------------------------- Noah Snavely Associate Professor Email: [email protected] Dept. of Computer Science Phone: (607) 255 4280 Cornell University URL : www.cs.cornell.edu/~snavely 307 Gates Hall Ithaca, NY 14853 -------------------------------------------------------------------

[snavely]

I tried running that dataset myself and got a good reconstruction (after resizing the images by 50%). See attached Meshlab screenshot. I am not sure what went wrong in your case, but it looks like the image matches are wrong. You could try rerunning from scratch, because if you rerun in the same directory some cached files may corrupt the results. Or I could send you the output of my run (keeping in mind it uses half-sized images). Noah On Sun, Feb 12, 2017 at 11:45 PM Noah Snavely <[email protected]> wrote:

…

I will look into that. One comment about libsiftfast, which I forgot to mention but you may have already figured out -- I believe it outputs features in a slightly different format from Lowe's sift -- I believe libsiftfast gives 2D image coordinates in (x, y) order, whereas Lowe's sift gives them in (y, x) order. Noah On Sun, Feb 12, 2017 at 11:40 PM Alberto Mardegan < ***@***.***> wrote: I'm using these images: https://github.com/rperrot/ReconstructionDataSet/tree/master/MirebeauStHilaireStatue I want to make a comparison among SfM software, so I'm trying the same dataset with bundler, mve, colmap, VisualSfM, openMVG, etc. This dataset seems to work fine with the other programs, so it's probably a matter of giving bundler the right options. Any hints will be very appreciated :-) — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#46 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABt6q-Yn01D8ZJN_w8DJ8bK9k0wxFaBiks5rcAj3gaJpZM4L72Fc> . -- ------------------------------------------------------------------- Noah Snavely Associate Professor Email: ***@***.*** Dept. of Computer Science Phone: (607) 255 4280 <(607)%20255-4280> Cornell University URL : www.cs.cornell.edu/~snavely 307 Gates Hall Ithaca, NY 14853 ------------------------------------------------------------------- --

------------------------------------------------------------------- Noah Snavely Associate Professor Email: [email protected] Dept. of Computer Science Phone: (607) 255 4280 Cornell University URL : www.cs.cornell.edu/~snavely 307 Gates Hall Ithaca, NY 14853 -------------------------------------------------------------------

[mardy]

Did you use sift or siftfast? I've yet to verify how things work if I try to swap x and y in siftfast. Maybe that's the issue. I'll try tonight, and let you know.

[snavely]

My run was with SIFT, not SIFTFAST. Noah

On Tue, Feb 14, 2017 at 12:24 AM Alberto Mardegan ***@***.***> wrote: Did you use sift or siftfast? I've yet to verify how things work if I try to swap x and y in siftfast. Maybe that's the issue. I'll try tonight, and let you know. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#46 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABt6q8ZrNQaKfuw4fH40mo3VRFXaNImOks5rcWS3gaJpZM4L72Fc> .

--

…

------------------------------------------------------------------- Noah Snavely Associate Professor Email: [email protected] Dept. of Computer Science Phone: (607) 255 4280 Cornell University URL : www.cs.cornell.edu/~snavely 307 Gates Hall Ithaca, NY 14853 -------------------------------------------------------------------

[mardy]

I must have done something wrong when preparing the images list. Well, I just run the python script to generate it, but obviously it did something wrong. Now I just tried running the RunBundler.sh from a clean directory where I only copied the JPEG files, and it worked (with siftfast). The generated point cloud is, however, a bit strange. It seems it contains the wall and the statues (I'm still referring to those images I linked above) but also lots of point which lie on a plane which I don't think should be there. Did you notice that too? Anyway, on another topic: I've build bundler as a snap package (see https://snapcraft.io), so that even non programmers will be able to install it -- it should work on all the major distributions. Would you like me to contribute the snapcraft.yaml file (that is, the "recipe" needed to create the snap package) to this repository? It's basically this file here: https://gitlab.com/mardy/snaps/blob/master/bundler/snapcraft.yaml I've uploaded bundler in the snap store as "bundler-mardy" in order to make it clear that it's just my effort and not an official thing. But if you want to try it, and you like the idea, I can rename it to "bundler" and share the upload rights with you (in that case, I also need to know your e-mail address). Let me know how you feel about this, and thanks a lot for your software!

[mardy]

About my reconstruction: I do get a noticeably better result if I modify the siftfast tool to swap columns with rows in its output, so your suggestion was probably right.

[mardy]

After verifying the images alignment with the point cloud with MeshLab, I have to walk back my last remark: siftfast is not swapping x with y.

bundler is doing a fair job at reconstructing the scene (I get a point cloud of about 12000 points), but it seems that a few images are not being used for reconstruction, causing poor details on the most interesting parts.

Here's the bundle log