Photogrammetry?

Meant this to be edited into previous post but it wouldn’t save for some reason:

PS: I can open my point-clouds in the GUI, and they’re unrecognizeable, but the positions of the camera relative to the model look right. I’m not sure, but I THINK the GUI would allow me to select a subset of photos and render the model on that basis. Perhaps less is more and the right small set of images will give cleaner results than the large set. Too bad I can’t find good documentation of the GUI online. If I can figure out how to use it and get reliably good results, maybe I’ll write a wiki how-to, but that’s a free-time project and I’m running out of week-end.

PPS: Hmm, I opened the cleaned point cloud in UMVE, and then I opened the object file, and this time it didn’t crash.

Hi
It looks like most of the examples use 11 shots? Hmmm I think I will need to try here with something…

Lets see how it all goes but I’m out of ideas on the software side…

Sorry, multiple irons in the fire today. Duty called and I had to put hobbies on hold.

So, instead of typical user documentation, MVE has scientific papers. I need to read some, and do some experiments. There’s obviously a skill to obtaining the images, in addition to running the software. You’ve packaged a full command-line pipeline and a partially-functional GUI for me to play with, but I’ll probably need several evenings after work to soak up the knowledge to test this properly.

In the meantime, I think it’s great you’re tackling this hole in openSUSE’s repertoire. From my research, the old favorite photogrammetry app is VisualSFM, but it hasn’t been maintained for half a decade and it seems to need deprecated dependencies.

The new favorite is COLMAP, but it only gets to the sparse cloud without CUDA (which requires an nvidia card). Evidently it’s slower than some but yields more thorough results. For those without nvidia, it prepares excellent input for openMVS, but as I reported, opebMVS doesn’t seem to like jpegs. Did you find out why not?

In any case, people seriously into photogrammetry are probably using nvidia, and they’ll be looking for COLMAP; I just won’t be the one to test it. But my friend might - he says he finds linux delightful so far. The computer I gave him is better than the one I kept, in all respects except the damaged case that’s too fragile for me to cart around anymore. If you tackle that one next, there’s a google group where the program’s author responds.

As for me, I’ll continue to report on my experiements here and hopefully get some good results with UMVE; it just may be a couple of days in between. Thanks again. Unfortunately, the forum engine will only let me star one post at a time. -GEF

Your experiment sounds interesting for essay writers, but not in the cards at the moment because 1) my ssd is too small, 2) ironically I gave my only spare computer to the friend on whose behalf I’m now researching photogrammetry software.

On Mon 16 Jul 2018 01:46:03 AM CDT, gfagan wrote:

Sorry, multiple irons in the fire today. Duty called and I had to put
hobbies on hold.

So, instead of typical user documentation, MVE has scientific papers. I
need to read some, and do some experiments. There’s obviously a skill to
obtaining the images, in addition to running the software. You’ve
packaged a full command-line pipeline and a partially-functional GUI for
me to play with, but I’ll probably need several evenings after work to
soak up the knowledge to test this properly.

In the meantime, I think it’s great you’re tackling this hole in
openSUSE’s repertoire. From my research, the old favorite photogrammetry
app is VisualSFM, but it hasn’t been maintained for half a decade and it
seems to need deprecated dependencies.

The new favorite is COLMAP, but it only gets to the sparse cloud without
CUDA (which requires an nvidia card). Evidently it’s slower than some
but yields more thorough results. For those without nvidia, it prepares
excellent input for openMVS, but as I reported, opebMVS doesn’t seem to
like jpegs. Did you find out why not?

In any case, people seriously into photogrammetry are probably using
nvidia, and they’ll be looking for COLMAP; I just won’t be the one to
test it. But my friend might - he says he finds linux delightful so far.
The computer I gave him is better than the one I kept, in all respects
except the damaged case that’s too fragile for me to cart around
anymore. If you tackle that one next, there’s a google group where the
program’s author responds.

As for me, I’ll continue to report on my experiements here and hopefully
get some good results with UMVE; it just may be a couple of days in
between. Thanks again. Unfortunately, the forum engine will only let me
star one post at a time. -GEF

Hi
Now looking at colmap, but some of these apps are so distribution
specific :frowning: I need to do some patching for the eigen check which is
failing…

Oh and also pushed mve-texturing and mve to the graphics repo, also got
them to re-enable Tumbleweed builds for meshlab. So in the near future
use that repo… :wink:


Cheers Malcolm °¿° SUSE Knowledge Partner (Linux Counter #276890)
SLES 15 | GNOME Shell 3.26.2 | 4.12.14-23-default
If you find this post helpful and are logged into the web interface,
please show your appreciation and click on the star below… Thanks!

That was you? I re-installed last night to get rid of kruft from trying to compile stuff (after creating a vbox for any future adventures in that vein), and I noticed that meshlab’s now in the experimental repo instead of just community. Thanks!

From what I can tell, openMVG is working fine (except it didn’t come with the sensorwidth list - just a text file I had to download), so maybe it deserves a promotion, too. I just can’t finish the process with openMVS.

As for COLMAP, there’s a forum post from somebody who got it working, but Tumbleweed has changed a lot since then with gcc 8, so that success might not be relevant. -GEF

On Mon 16 Jul 2018 04:56:03 PM CDT, gfagan wrote:

That was you? I re-installed last night to get rid of kruft from trying
to compile stuff (after creating a vbox for any future adventures in
that vein), and I noticed that meshlab’s now in the experimental repo
instead of just community. Thanks!

From what I can tell, openMVG is working fine (except it didn’t come
with the sensorwidth list - just a text file I had to download), so
maybe it deserves a promotion, too. I just can’t finish the process with
openMVS.

As for COLMAP, there’s a forum post from somebody who got it working,
but Tumbleweed has changed a lot since then with gcc 8, so that success
might not be relevant. -GEF

Hi
Well ceres-solver has been the pain, but getting it to build now, it’s
a colmap dependency, so maybe you will see something in my test repo
later on :wink:

DO you have a link to the file you downloaded, and also where you
needed to place.


Cheers Malcolm °¿° SUSE Knowledge Partner (Linux Counter #276890)
SLES 15 | GNOME Shell 3.26.2 | 4.12.14-23-default
If you find this post helpful and are logged into the web interface,
please show your appreciation and click on the star below… Thanks!

Hi
Sorted out ceres-solver… here is colmap for you to test…
https://build.opensuse.org/package/show/home:malcolmlewis:TESTING/colmap

Sorry to report, COLMAP crashes right off the bat (feature extraction stage). My computer can’t test dense point cloud because I don’t have nvidia, but I should be able to handle up to sparse cloud. -GEF

Hi
Make sure you uncheck the box to use the gpu on any of the screens… :wink:

Currently running feature matching…

http://thumbs2.imagebam.com/6c/c3/df/0f1acf922236874.jpg](ImageBam)

For sensorwidth file, I found it here:

https://github.com/openMVG/openMVG/blob/master/src/openMVG/exif/sensor_width_database/sensor_width_camera_database.txt

As for where it needs to be placed, the script I referenced above (post #13) looks for it in /usr/local/share/openMVG.

-GEF

Missed that - feeling stupid about it. So I launched automatic reconstruction on a large set of photos I took instead of one of the small sample sets, and I’m feeling stupid about that too because it’s been churning for an hour. Still, that’s beeter than a crash. I’ll report back when it’s done. =GEF

Well, as of this morning the automatic reconstruction was still crunching, but I had to cancel and back up my laptop. Perhaps I started too ambitiously, though there were fewer than 50 images in the set. Tonight I’ll try it again one step at a time. -GEF

>Currently running feature matching…

How’d that go. I tried the castle sample set from pmoulin, and the extraction seemed to take a long time (not sure how long because I fell asleep), and the matching hasn’t finished within 8hr (which is about as long as I can leave my laptop running at a time). With that same set, the whole process of generating a tectured model on that same set took far less than that!

GEF

On Fri 20 Jul 2018 09:46:03 AM CDT, gfagan wrote:

>Currently running feature matching…

How’d that go. I tried the castle sample set from pmoulin, and the
extraction seemed to take a long time (not sure how long because I fell
asleep), and the matching hasn’t finished within 8hr (which is about as
long as I can leave my laptop running at a time). With that same set,
the whole process of generating a tectured model on that same set took
far less than that!

GEF

Hi
I reduced the block_size down from 60 to 5 for testing, it still took
awhile… but did finish…


Cheers Malcolm °¿° SUSE Knowledge Partner (Linux Counter #276890)
SLES 15 | GNOME Shell 3.26.2 | 4.12.14-23-default
If you find this post helpful and are logged into the web interface,
please show your appreciation and click on the star below… Thanks!

On COLMAP, my buddy who has the nvidia GPU reports the same experience I had with GPU checked: the program just winks out. With GPU uncecked, he reports it works fairly quick, but the resulting sparse cloud seems extra-sparse.

As for me, even with lower block size I couldn’t get through matching overnight, but I may have done something wrong. Remember I tried the large set of photos I took myself, never got through 'em, then tried on the Sceaux castle set, extraction worked, started the matching, but I have a sneaky suspicion that it was trying to match the first, not second, set of extractions. So, next step is to wipe out thewhole directory structure and try again.

GEF

super interesting thread, hope those open source photogrammetry apps will start working on OpenSUSE.
On my end I’ve used Agisoft PhotoScan (proprietary app) on Leap 15 and it worked without a hitch.

Hi Pshemas, thanks for the report on Photoscan. I’ve read that it’s great, in that it’s what everything else gets compared to, and it supports GPU-based computation with non-nvidia processors. UNfortunately, while the academic price is reasonable, I’m neither student nor professor, and the commercial price is well out of my range just for a hobby - actually a potential hobby. As I said above, I’m mainly investigating photogrammetry on behalf of a friend who would like to change his career to 3D animation, but the job he’s got now won’t pay for the tools with which to build a portfolio. -GEF

Hi Malcolm, I keep trying to give you kudos but the site wants me to share the love more.

Seems I was right about COLMAP: After I deleted all the files it had created and started over with the Sceaux Castle set, it generated quite a recognizeable sparse point cloud - moreso than openMVG, and it didn’t take forever. Then again, it also stayed cool - the reason it never completed before may be that it froze up due to heat, but I didn’t have the thermal monitor widget running at the time.

I did figure out how to export a sparse cloud from COLMP for viewing in Meshlab, but I haven’t figured out how to generate the dense cloud and texture with other tools.

With UMVE, I can’t seem to do more than load a project. Click on the wrong thing, and it crashes. I read a paper that said it “walks you through” the process. The same paper says the process starts with SfM, and in screenshots of UMVE I’ve seen online, there’s actually an SfM tab, but when I open the program, I only see View and Scene Inspection tabs.

Next project, as threatened previously, is use openMVG as the beginning of the MVE pipeline, if I can figure out how, and see if the results are cleaner than with MVE alone. The reason they might be is that camera parameters come from a datafile instead of being estimated by comparing photos. The reason they might not be better is that the estimate is based on EXIF info contained in each image which may be as good as or better than what’s in the datafile.

According to this (http://openmvg.readthedocs.io/en/latest/software/SfM/SfM/):

In order to use easily the Sequential or the Global pipeline, ready to used script are exported in your build directory:


  - openMVG_Build/software/SfM/SfM_SequentialPipeline.py
  - openMVG_Build/software/SfM/SfM_GlobalPipeline.py

But I can’t find 'em. Any idea where they live when installed via package manager instead of locally compiled? -GEF