<div dir="ltr">the LSD slam page has some ply files you can open in mesh lab -- I was doing my best to get a mesh from the point cloud, but I hjave nevr used meshlab before and all I was getting was globs. Also their source is GNUv3, so we can use it. They are using ROS, so we would need change some stuff around to get it to work independently -- ROS has a high learning curve and is definitely not suitable for what you guys want to do.<div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Mar 16, 2015 at 10:40 PM, Stephen Mather <span dir="ltr"><<a href="mailto:stephen@smathermather.com" target="_blank">stephen@smathermather.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi Cole,<div><br></div><div>Awesome video. That's really illustrative. I look forward to digging into the code.</div><div><br></div><div>In my mind, lsdslam and similar dense optical flow techniques are brilliant, and would solve a few ODM problems, not the least of which is performing matching on continuously variable surfaces with otherwise few matchable features (i.e. <a href="https://twitter.com/reprojected/status/576142074522648576/photo/1" target="_blank">https://twitter.com/reprojected/status/576142074522648576/photo/1</a> ). The one thing about them is their tendency (as I understand it) to drift, so I think that there is still a place for feature matching to avoid having to calculate large loop closures, as this may not always be practical for input datasets.</div><div><br></div><div>Unless I misunderstand the process, the matching is not all pixels to all images but first feature identification, then match. Only once this is done does PMVS perform full pixel matching, which is the shortest portion of the toolchain aside from mesh and texture.</div><div><br></div><div>Regardless of approach, match / dense optical flow, or hybrid, it will still be useful to use image ephemeris to aid with pre-matching, especially in cases where yaw/pitch/roll in addition to location are known.</div><div><br></div><div>Best,<br></div><div>Steve</div><div><br></div><div><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Mar 16, 2015 at 7:33 PM, Cole <span dir="ltr"><<a href="mailto:colek42@gmail.com" target="_blank">colek42@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">How is the point matching being done with bundler? It seems like it is just iterating over every pixel of every image. There are much better methods, especially if we have access to IMU, Gyro, and GPS data (you can buy a 9 axis sensor for about $50 these days). Even without this sensor data, state estimation in video can be calculated from one frame to the next using dense optical flow. I wrote something using a similar concept for image stabilization. Demo here: <a href="https://www.youtube.com/watch?v=LIcYE9eBNjE" target="_blank">https://www.youtube.com/watch?v=LIcYE9eBNjE</a> This was done in real time, using python and OpenCV. Code is here (free for use) <a href="https://github.com/colek42/TrackIt" title="https://github.com/colek42/TrackIt" rel="nofollow" dir="ltr" style="margin:0px;padding:0px;border:0px;font-size:13px;color:rgb(51,51,51);text-decoration:none;line-height:17px;background-image:initial;background-repeat:initial" target="_blank">https://github.com/colek42/TrackIt/tree/master/catkin/src/stabilize/src</a> ( this is just test code, prototyping for some C++, I apologize in advance for it's ugliness)<div><br></div><div><div>see <a href="http://vision.in.tum.de/research/lsdslam" target="_blank">http://vision.in.tum.de/research/lsdslam</a> . Their code is not license compatible, but is a good example of what can be done as far as efficiency, and how far the current tool chain is away from state of the art, as far as point matching.</div></div><div><br></div><div>I am working on the lens correction code tonight. I have a pull request for a script that will have you input a checkerboard image, and a dir with all the images or video you would like processed. It will depend on python 2.74 and OpenCV. </div><div><br></div><div>I wish I could give the project some more time, but I am currently working full time, taking way too many credits, and a family I like to spend some time with. My schedule should clear up in a couple months and I should be able to make some progress on some of this stuff</div><div><br></div><div>v/r</div><div>NJK</div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Mar 16, 2015 at 3:01 PM, <span dir="ltr"><<a href="mailto:opendronemap-dev-request@lists.osgeo.org" target="_blank">opendronemap-dev-request@lists.osgeo.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Send OpenDroneMap-dev mailing list submissions to<br>
<a href="mailto:opendronemap-dev@lists.osgeo.org" target="_blank">opendronemap-dev@lists.osgeo.org</a><br>
<br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
<a href="http://lists.osgeo.org/cgi-bin/mailman/listinfo/opendronemap-dev" target="_blank">http://lists.osgeo.org/cgi-bin/mailman/listinfo/opendronemap-dev</a><br>
or, via email, send a message with subject or body 'help' to<br>
<a href="mailto:opendronemap-dev-request@lists.osgeo.org" target="_blank">opendronemap-dev-request@lists.osgeo.org</a><br>
<br>
You can reach the person managing the list at<br>
<a href="mailto:opendronemap-dev-owner@lists.osgeo.org" target="_blank">opendronemap-dev-owner@lists.osgeo.org</a><br>
<br>
When replying, please edit your Subject line so it is more specific<br>
than "Re: Contents of OpenDroneMap-dev digest..."<br>
<br>
<br>
Today's Topics:<br>
<br>
1. Ideas for speeding up the Point Matching (Alex Mandel)<br>
2. Re: Ideas for speeding up the Point Matching (Stephen Mather)<br>
3. Re: Ideas for speeding up the Point Matching (Stephen Mather)<br>
<br>
<br>
----------------------------------------------------------------------<br>
<br>
Message: 1<br>
Date: Sun, 15 Mar 2015 20:00:56 -0700<br>
From: Alex Mandel <<a href="mailto:tech_dev@wildintellect.com" target="_blank">tech_dev@wildintellect.com</a>><br>
To: <a href="mailto:opendronemap-dev@lists.osgeo.org" target="_blank">opendronemap-dev@lists.osgeo.org</a><br>
Subject: [OpenDroneMap-dev] Ideas for speeding up the Point Matching<br>
Message-ID: <<a href="mailto:55064768.4010109@wildintellect.com" target="_blank">55064768.4010109@wildintellect.com</a>><br>
Content-Type: text/plain; charset=utf-8<br>
<br>
So 2 days in to running ~1000 images I started pondering how to speed up<br>
the point matching step.<br>
<br>
Here's the basic idea, split the list of images into related chunks,<br>
process those chunks and then process a slice of overlap from 2 adjacent<br>
chunks.<br>
<br>
This nice part is that this idea will work for either time/numeric<br>
ordered or GeoExif grouping.<br>
<br>
Here's the basic idea, take a number of photos that is reasonable to<br>
process like 100. Now take your set of photos, 1000 and divide it by<br>
100. So you first do 10 sets of a 100. Then you take 1/2 or 1/3 or 1/4<br>
of two adjacent sets. So the last 50 of set 1 and first 50 of set 2 (for<br>
1/2), that gives you 9 additional sets of 100 but you only have to do<br>
1/2 of the matches, only the ones that have a photo from a different<br>
original set.<br>
<br>
Here's the math:<br>
n!/(r!(n-r)!)<br>
<a href="http://www.calculatorsoup.com/calculators/discretemathematics/combinations.php" target="_blank">http://www.calculatorsoup.com/calculators/discretemathematics/combinations.php</a><br>
<br>
n is number of photos in a set<br>
r is 2, number of photos in a pair<br>
<br>
100 Photos is 4950 pairs. If you do just 1000 you get 499,500 pairs to<br>
check. If you do what I said above, groups of 100, with 50% overlap you<br>
get 71,775 pairs to check ((10*4950)+9(4950/2))<br>
<br>
Now for the fancy part, the dumb application of this to GeoExif is to<br>
take the bbox of all the photos, take the longer side of the box and<br>
divide it by 10, so you make 10 new rectangles and run each of those as<br>
a set, then run the 9 overlap regions. Long term we can get smarter with<br>
how we pick the regions to ensure ~100 images per region.<br>
<br>
So steps to accomplish this,<br>
1. write a short script to make lists of photos in each set to run.<br>
2. figure out how to send the lists to the point matching tool<br>
2a. figure out how to make the point matching tool skip matches done in<br>
a previous set.<br>
3. Continue from there as usual.<br>
<br>
Feedback anyone?<br>
<br>
Thanks,<br>
Alex<br>
<br>
<br>
------------------------------<br>
<br>
Message: 2<br>
Date: Sun, 15 Mar 2015 23:15:25 -0400<br>
From: Stephen Mather <<a href="mailto:stephen@smathermather.com" target="_blank">stephen@smathermather.com</a>><br>
To: Alex Mandel <<a href="mailto:tech@wildintellect.com" target="_blank">tech@wildintellect.com</a>><br>
Cc: <a href="mailto:opendronemap-dev@lists.osgeo.org" target="_blank">opendronemap-dev@lists.osgeo.org</a><br>
Subject: Re: [OpenDroneMap-dev] Ideas for speeding up the Point<br>
Matching<br>
Message-ID:<br>
<CAPkJWLVZdGn=<a href="mailto:pn4oXQw2D9YdZqGHidUa1RouKBkORfx4npiUiw@mail.gmail.com" target="_blank">pn4oXQw2D9YdZqGHidUa1RouKBkORfx4npiUiw@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Hi Alex,<br>
<br>
One thought I had was to use geolocations in the exif, pipe those values<br>
through something really dumb like geohash, then sort by geohash, thus<br>
clustering similar values, and (I think) you can limit the number of images<br>
that match tries to match to some reasonable number like you propose, so<br>
that it would still chunk through the dataset as a single model, but limit<br>
the matching to some moving window based on image order as determined by<br>
the hash.<br>
<br>
Going to reread your write up in the morning when I am smarter... :) . It's<br>
undoubtedly better than a geohash hack... .<br>
<br>
Best,<br>
Steve<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.osgeo.org/pipermail/opendronemap-dev/attachments/20150315/36293eae/attachment-0001.html" target="_blank">http://lists.osgeo.org/pipermail/opendronemap-dev/attachments/20150315/36293eae/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 3<br>
Date: Mon, 16 Mar 2015 13:13:51 -0400<br>
From: Stephen Mather <<a href="mailto:stephen@smathermather.com" target="_blank">stephen@smathermather.com</a>><br>
To: Alex Mandel <<a href="mailto:tech@wildintellect.com" target="_blank">tech@wildintellect.com</a>><br>
Cc: <a href="mailto:opendronemap-dev@lists.osgeo.org" target="_blank">opendronemap-dev@lists.osgeo.org</a><br>
Subject: Re: [OpenDroneMap-dev] Ideas for speeding up the Point<br>
Matching<br>
Message-ID:<br>
<CAPkJWLURZeG+s-W1VrQzb3QsnA9_=jm_t1=<a href="mailto:oHWok6HpsNuewpQ@mail.gmail.com" target="_blank">oHWok6HpsNuewpQ@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Ok -- this is deep. So this approach reduces the factorial load<br>
independently of geography, with the exception that the subset locations<br>
are chosen by geography?<br>
<br>
Thanks,<br>
Best,<br>
Steve<br>
<br>
<br>
<br>
On Sun, Mar 15, 2015 at 11:00 PM, Alex Mandel <<a href="mailto:tech_dev@wildintellect.com" target="_blank">tech_dev@wildintellect.com</a>><br>
wrote:<br>
<br>
> So 2 days in to running ~1000 images I started pondering how to speed up<br>
> the point matching step.<br>
><br>
> Here's the basic idea, split the list of images into related chunks,<br>
> process those chunks and then process a slice of overlap from 2 adjacent<br>
> chunks.<br>
><br>
> This nice part is that this idea will work for either time/numeric<br>
> ordered or GeoExif grouping.<br>
><br>
> Here's the basic idea, take a number of photos that is reasonable to<br>
> process like 100. Now take your set of photos, 1000 and divide it by<br>
> 100. So you first do 10 sets of a 100. Then you take 1/2 or 1/3 or 1/4<br>
> of two adjacent sets. So the last 50 of set 1 and first 50 of set 2 (for<br>
> 1/2), that gives you 9 additional sets of 100 but you only have to do<br>
> 1/2 of the matches, only the ones that have a photo from a different<br>
> original set.<br>
><br>
> Here's the math:<br>
> n!/(r!(n-r)!)<br>
><br>
> <a href="http://www.calculatorsoup.com/calculators/discretemathematics/combinations.php" target="_blank">http://www.calculatorsoup.com/calculators/discretemathematics/combinations.php</a><br>
><br>
> n is number of photos in a set<br>
> r is 2, number of photos in a pair<br>
><br>
> 100 Photos is 4950 pairs. If you do just 1000 you get 499,500 pairs to<br>
> check. If you do what I said above, groups of 100, with 50% overlap you<br>
> get 71,775 pairs to check ((10*4950)+9(4950/2))<br>
><br>
> Now for the fancy part, the dumb application of this to GeoExif is to<br>
> take the bbox of all the photos, take the longer side of the box and<br>
> divide it by 10, so you make 10 new rectangles and run each of those as<br>
> a set, then run the 9 overlap regions. Long term we can get smarter with<br>
> how we pick the regions to ensure ~100 images per region.<br>
><br>
> So steps to accomplish this,<br>
> 1. write a short script to make lists of photos in each set to run.<br>
> 2. figure out how to send the lists to the point matching tool<br>
> 2a. figure out how to make the point matching tool skip matches done in<br>
> a previous set.<br>
> 3. Continue from there as usual.<br>
><br>
> Feedback anyone?<br>
><br>
> Thanks,<br>
> Alex<br>
> _______________________________________________<br>
> OpenDroneMap-dev mailing list<br>
> <a href="mailto:OpenDroneMap-dev@lists.osgeo.org" target="_blank">OpenDroneMap-dev@lists.osgeo.org</a><br>
> <a href="http://lists.osgeo.org/cgi-bin/mailman/listinfo/opendronemap-dev" target="_blank">http://lists.osgeo.org/cgi-bin/mailman/listinfo/opendronemap-dev</a><br>
><br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.osgeo.org/pipermail/opendronemap-dev/attachments/20150316/82090550/attachment-0001.html" target="_blank">http://lists.osgeo.org/pipermail/opendronemap-dev/attachments/20150316/82090550/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
_______________________________________________<br>
OpenDroneMap-dev mailing list<br>
<a href="mailto:OpenDroneMap-dev@lists.osgeo.org" target="_blank">OpenDroneMap-dev@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/cgi-bin/mailman/listinfo/opendronemap-dev" target="_blank">http://lists.osgeo.org/cgi-bin/mailman/listinfo/opendronemap-dev</a><br>
<br>
<br>
End of OpenDroneMap-dev Digest, Vol 2, Issue 3<br>
**********************************************<br>
</blockquote></div><br></div>
<br>_______________________________________________<br>
OpenDroneMap-dev mailing list<br>
<a href="mailto:OpenDroneMap-dev@lists.osgeo.org" target="_blank">OpenDroneMap-dev@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/cgi-bin/mailman/listinfo/opendronemap-dev" target="_blank">http://lists.osgeo.org/cgi-bin/mailman/listinfo/opendronemap-dev</a><br>
<br></blockquote></div><br></div></div>
</blockquote></div><br></div>