On 3 Jan 2018, at 06:46, Alex Myczko <sengun@phys.ethz.ch> wrote:
Hi Johannes,
Sorry for the late reply. Happy New Year!
I merged your sample manual page for the main COLMAP GUI executable.
Thanks again.
Thank you!
The other executables should also be exposed to the user and are not
called internally.
Ah, that wasn't clear to me.
Each executable is self-contained and does not rely
on the other ones.
Very important bit to know.
Would the following file structure work for Debian:
/usr/bin/colmap (main GUI exe)
/usr/bin/colmap-cli/feature_extractor
/usr/bin/colmap-cli/feature_matcher
etc.
I think that's impractical, since $PATH usually doesn't contain
/usr/bin/colmap-cli
but there's several options (look at the GMT plotting tools in
Debian):
1) have them be just like they are (and write manual pages for all of
them)
2) make one wrapper script, say called colmap-cli (accepting first
parameter feature_extractor and further parameters, call them in
/usr/lib/colmap/) (gmt does it so), write manual page only for
colmap-cli
I would then create a new folder at doc/manual/ with a separate
manual
for each executable? Are there any conventions for the names of
these
files or can you just map them to the binaries in the config?
Manual pages, usually have the same name as the binary to be called.
man man
gives a little overview:
1 Executable programs or shell commands
2 System calls (functions provided by the kernel)
3 Library calls (functions within program libraries)
4 Special files (usually found in /dev)
5 File formats and conventions eg /etc/passwd
6 Games
7 Miscellaneous (including macro packages and conventions),
e.g. man(7), groff(7)
8 System administration commands (usually only for root)
9 Kernel routines [Non standard]
So it'd be feature_extractor.1 etc. There's help2man, and pod2man to
help you write
the manual pages.
In addition, COLMAP ideally is compiled with CUDA. Is there a way to
provide two different versions that users can install?
Again, debian normally is only free software, and CUDA is not. So as
a binary no.
But it is very easy and common (see atlas package recommends people
to build it from
source, to optimize for destination cpu) to have the source package
downloaded, and built
where it's supposed to be run (optimized, or in this case, linked
against CUDA)
So it'd be useful to (Debian and Ubuntu users to have colmap packaged
officially).
Thank you!
Alex
Thanks for your help.
Johannes
On Dec 15, 2017, at 1:06 AM, Alex Myczko <sengun@phys.ethz.ch>
wrote:
Hi Johannes,
I would be happy to visit at some point but I am currently on a 3
month research visit in the US, which is why I am rather busy at
the
moment. I will try to look into all of this on the coming weekend.
Great news. Enjoy your research visit to the US.
Thanks for trying to looking into helping to get colmap packaged
officially for Debian
(and Ubuntu will just grab a copy and profit).
Regarding your question about Neuschwanstein: yes, you should be
able
to get a reconstruction of this. The only tricky part would be
that
you captured the video through glass, which means you will have
some
complex lens distortion. I would try to extract one frame every
second
or so from the video and then just feed it into COLMAP.
Thanks for the tip.
Cheers,
Cheers,
Johannes
On 12 Dec 2017, at 03:31, Alex Myczko <sengun@phys.ethz.ch>
wrote:
Hi Johannes,
Thanks for reaching out and it would be fantastic if there was
an
official Debian build. I saw your post on github earlier but I
just
have not had time to look into it so far. I am sorry and I will
try to
get back to you over the next days.
That's fine. Feel free to visit us (I'm on Hoenggerberg).
I was able to build i386/amd64 packages of the software on Ubuntu
PPA (for bionic):
https://launchpad.net/~gagarin/+archive/ubuntu/bionic/+packages
However for official Debian packages, aside the mentioned thing,
also binaries
that are not supposed to be run by the user, should go to
/usr/lib/colmap and be called
there if needed by the software (gui, colmap) interally only.
/usr/bin/automatic_reconstructor
/usr/bin/bundle_adjuster
/usr/bin/color_extractor
/usr/bin/database_creator
/usr/bin/dense_fuser
/usr/bin/dense_mesher
/usr/bin/exhaustive_matcher
/usr/bin/feature_extractor
/usr/bin/feature_importer
/usr/bin/image_rectifier
/usr/bin/image_registrator
/usr/bin/image_undistorter
/usr/bin/mapper
/usr/bin/matches_importer
/usr/bin/model_aligner
/usr/bin/model_analyzer
/usr/bin/model_converter
/usr/bin/model_merger
/usr/bin/model_orientation_aligner
/usr/bin/point_triangulator
/usr/bin/rig_bundle_adjuster
/usr/bin/sequential_matcher
/usr/bin/spatial_matcher
/usr/bin/transitive_matcher
/usr/bin/vocab_tree_builder
/usr/bin/vocab_tree_matcher
/usr/bin/vocab_tree_retriever
I don't know if those or only meant to be used internally. If
not, they'll need manual pages.
All binaries in /usr/bin/ do, I think I made a minimal one for
colmap.
Am I right I could use the software to make a 3d model of my
video of Schloss Neuschwanstein?
https://www.flickr.com/photos/aiei/25133869388/
Best,
Alex
Best,
Johannes
On 11 Dec 2017, at 03:44, Alex Myczko <sengun@phys.ethz.ch>
wrote:
hi Johannes
we have got users at D-BAUG that use colmap, so we provide them
with prebuilt linux binaries (ubuntu 16.04).
since I made the effort to build a debian[1] package, it could
as well be an official debian package, however
debian requires the binaries be built with -O2 and no
-march=core2, and I'm out of ideas how to tell cmake
to not use those optimizations. any hints are welcome.
yours,
[1] https://bugs.debian.org/882326