Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

how to create a scene #469

Closed
xmof opened this issue Mar 7, 2019 · 7 comments
Closed

how to create a scene #469

xmof opened this issue Mar 7, 2019 · 7 comments

Comments

@xmof
Copy link

xmof commented Mar 7, 2019

Hi there, I recently installed mve for some 3d reconstruction projects, have installed all, compilation from source required some manually added include directories (libpng, libtiff, libjpeg) therefore my question could be due to that. Issuing make gave errors e.g. png.h not found, but I had them in my /usr/include/libpng directory. creating a link to /usr/include made the errors go away, however, I compiled the lines separately by issuing with extra include directories e.g. g++ ...... -I/usr/include/libpng .... because I didnt know how to change the makefile to do that for me.
Now I am trying to make scenes with makescene, (I am testing still, I issue: "apps/makescene/makescene -i" ) it creates the SCENE directory and reads from the IMAGES directory, but all it says is: "Skipping file , cannot load image ...

  1. could this be due to compilation problems?
  2. if so, how do I make the compiler find the right include directories which are basically subdirs of
    my /usr/include directory?
  3. and if not so, what else could be the problem?

all image files have my usr/group permissions, so do the directories.
Hope for your answer soon!

@xmof
Copy link
Author

xmof commented Mar 7, 2019

OK, problem semi-solved: I converted with Imagemagick from tif to jpg, didn't help much, still
Skipping file, cannot load image.
I just converted tif to png, just with "convert image.tif image.png" well, that seems to work:
says "Importing image: ... , writing MVE view ... etc.

I don't really understand why jpg and tiff don't work out fine (maybe I will try the extensions .jpeg and .tiff instead of .jpg and .tif ...) on the other hand, it is just a matter of few time to convert to png images
anyway.

@simonfuhrmann
Copy link
Owner

To add a global include path, use Makefile.inc and append it to the COMPILE.cc variable. Note however, that it should not be necessary to add the include path for, e.g., libpng. Your /usr/include should contain png.h, jpeglib.h, etc., which is the default include path. Provided that you installed libpng-dev, libjpeg-dev, or the correspondingly named packages on your system.

Why the JPEG and TIFF images don't work, however, is unclear. MVE provides support (also in makescene) for TIFF, PNG and JPEG. In fact, converting to PNG might have adverse effects as the EXIF tags (in case you want to run SfM) get lost, and focal length information may not be available.

@xmof
Copy link
Author

xmof commented Mar 8, 2019 via email

@xmof
Copy link
Author

xmof commented Mar 29, 2019 via email

@simonfuhrmann
Copy link
Owner

There is no support for parallelizing the SfM part on the pipeline. In theory, feature detection and matching could be split up on multiple machines and the resulting matches could be merged into a single file. But no work has been done on that. The depth map reconstruction, however, can trivially be parallelized. Each dmrecon command can be run on a separate image, or a range of images, with the options -m or -l respectively.

If you're willing to invest a significant amount of time to implement a variation of sfmrecon that runs on multiple machines, I can give you some pointers, but for the time being I recommend you look into the --video-matching option, which only matches to previous frames, but this is obviously a big limitation as it doesn't detect loops and such.

@xmof
Copy link
Author

xmof commented Mar 30, 2019 via email

@simonfuhrmann
Copy link
Owner

I really don't understand why you would run makescene or sfmrecon multiple times. Just calling it more often doesn't make it faster, but slower because you're running the same processing multiple times. I'll close this for now. Feel free to reopen.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants