Upload 3.12 legacy + update doc (#17)

Author: B1ueber2y

_sources/cameras.rst.txt

@@ -5,29 +5,29 @@ COLMAP implements different camera models of varying complexity. If no intrinsic
 parameters are known a priori, it is generally best to use the simplest camera
 model that is complex enough to model the distortion effects:
 
-- `SIMPLE_PINHOLE`, `PINHOLE`: Use these camera models, if your images are
+- ``SIMPLE_PINHOLE``, ``PINHOLE``: Use these camera models, if your images are
   undistorted a priori. These use one and two focal length parameters,
   respectively. Note that even in the case of undistorted images, COLMAP could
   try to improve the intrinsics with a more complex camera model.
-- `SIMPLE_RADIAL`, `RADIAL`: This should be the camera model of choice, if the
+- ``SIMPLE_RADIAL``, ``RADIAL``: This should be the camera model of choice, if the
   intrinsics are unknown and every image has a different camera calibration,
   e.g., in the case of Internet photos. Both models are simplified versions of
-  the `OPENCV` model only modeling radial distortion effects with one and two
+  the ``OPENCV`` model only modeling radial distortion effects with one and two
   parameters, respectively.
-- `OPENCV`, `FULL_OPENCV`: Use these camera models, if you know the calibration
+- ``OPENCV``, ``FULL_OPENCV``: Use these camera models, if you know the calibration
   parameters a priori. You can also try to let COLMAP estimate the parameters,
   if you share the intrinsics for multiple images. Note that the automatic
   estimation of parameters will most likely fail, if every image has a separate
   set of intrinsic parameters.
-- `SIMPLE_RADIAL_FISHEYE`, `RADIAL_FISHEYE`, `OPENCV_FISHEYE`, `FOV`,
-  `THIN_PRISM_FISHEYE`, `RAD_TAN_THIN_PRISM_FISHEYE`: Use these camera models
+- ``SIMPLE_RADIAL_FISHEYE``, ``RADIAL_FISHEYE``, ``OPENCV_FISHEYE``, ``FOV``,
+  ``THIN_PRISM_FISHEYE``, ``RAD_TAN_THIN_PRISM_FISHEYE``: Use these camera models
   for fisheye lenses and note that all other models are not really capable of
-  modeling the distortion effects of fisheye lenses. The `FOV` model is used by
-  Google Project Tango (make sure to not initialize `omega` to zero).
+  modeling the distortion effects of fisheye lenses. The ``FOV`` model is used by
+  Google Project Tango (make sure to not initialize ``omega`` to zero).
 
 You can inspect the estimated intrinsic parameters by double-clicking specific
 images in the model viewer or by exporting the model and opening the
-`cameras.txt` file.
+``cameras.txt`` file.
 
 To achieve optimal reconstruction results, you might have to try different
 camera models for your problem. Generally, when the reconstruction fails and the

_sources/cli.rst.txt

@@ -164,7 +164,7 @@ the available options, e.g.::
     $ colmap feature_extractor -h
 
         Options can either be specified via command-line or by defining
-        them in a .ini project file passed to `--project_path`.
+        them in a .ini project file passed to ``--project_path``.
 
           -h [ --help ]
           --project_path arg
@@ -195,7 +195,7 @@ the available options, e.g.::
 
 
 The available options can either be provided directly from the command-line or
-through a `.ini` file provided to ``--project_path``.
+through a ``.ini`` file provided to ``--project_path``.
 
 
 Commands

_sources/concepts.rst.txt

@@ -44,7 +44,7 @@ virtual cameras arranged to capture overlapping views used to create seamless
 In COLMAP, each sensor must be uniquely associated with exactly one rig. Each rig
 has a single reference sensor that defines its origin. For example, in a stereo
 camera rig, one camera is designated as the reference sensor with an identity
-`sensor_from_rig` pose, while the second camera’s pose is defined relative to
+``sensor_from_rig`` pose, while the second camera’s pose is defined relative to
 this reference. In a single-camera setup, the camera itself serves as the sole
 reference sensor for its rig.
 

_sources/database.rst.txt

@@ -20,7 +20,7 @@ The database contains the following tables:
 - two_view_geometries
 
 To initialize an empty SQLite database file with the required schema, you can
-either create a new project in the GUI or execute `src/colmap/exe/database_create.cc`.
+either create a new project in the GUI or execute ``src/colmap/exe/database_create.cc``.
 
 
 Rigs and Sensors
@@ -47,7 +47,7 @@ intrinsic parameters (focal length, principal point, distortion, etc.), while
 every image has separate extrinsic parameters (orientation and location).
 
 The intrinsic parameters of cameras are stored as contiguous binary blobs in
-`float64`, ordered as specified in ``src/colmap/sensor/models.h``. COLMAP only
+``float64``, ordered as specified in ``src/colmap/sensor/models.h``. COLMAP only
 uses cameras that are referenced by images, all other cameras are ignored.
 
 The ``name`` column in the images table is the unique relative path in the image
@@ -62,23 +62,23 @@ and ``camera_id > 0``.
 Keypoints and Descriptors
 -------------------------
 
-The detected keypoints are stored as row-major `float32` binary blobs, where the
+The detected keypoints are stored as row-major ``float32`` binary blobs, where the
 first two columns are the X and Y locations in the image, respectively. COLMAP
-uses the convention that the upper left image corner has coordinate `(0, 0)` and
-the center of the upper left most pixel has coordinate `(0.5, 0.5)`. If the
+uses the convention that the upper left image corner has coordinate ``(0, 0)`` and
+the center of the upper left most pixel has coordinate ``(0.5, 0.5)``. If the
 keypoints have 4 columns, then the feature geometry is a similarity and the
 third column is the scale and the fourth column the orientation of the feature
 (according to SIFT conventions). If the keypoints have 6 columns, then the
 feature geometry is an affinity and the last 4 columns encode its affine shape
 (see ``src/feature/types.h`` for details).
 
-The extracted descriptors are stored as row-major `uint8` binary blobs, where
+The extracted descriptors are stored as row-major ``uint8`` binary blobs, where
 each row describes the feature appearance of the corresponding entry in the
 keypoints table. Note that COLMAP only supports 128-D descriptors for now, i.e.
-the `cols` column must be 128.
+the ``cols`` column must be 128.
 
-In both tables, the `rows` table specifies the number of detected features per
-image, while `rows=0` means that an image has no features. For feature matching
+In both tables, the ``rows`` table specifies the number of detected features per
+image, while ``rows=0`` means that an image has no features. For feature matching
 and geometric verification, every image must have a corresponding keypoints and
 descriptors entry. Note that only vocabulary tree matching with fast spatial
 verification requires meaningful values for the local feature geometry, i.e.,
@@ -89,10 +89,10 @@ The rest of the reconstruction pipeline only uses the keypoint locations.
 Matches and two-view geometries
 -------------------------------
 
-Feature matching stores its output in the `matches` table and geometric
-verification in the `two_view_geometries` table. COLMAP only uses the data in
-`two_view_geometries` for reconstruction. Every entry in the two tables stores
-the feature matches between two unique images, where the `pair_id` is the
+Feature matching stores its output in the ``matches`` table and geometric
+verification in the ``two_view_geometries`` table. COLMAP only uses the data in
+``two_view_geometries`` for reconstruction. Every entry in the two tables stores
+the feature matches between two unique images, where the ``pair_id`` is the
 row-major, linear index in the upper-triangular match matrix, generated as
 follows::
 
@@ -102,23 +102,23 @@ follows::
         else:
             return 2147483647 * image_id1 + image_id2
 
-and image identifiers can be uniquely determined from the `pair_id` as::
+and image identifiers can be uniquely determined from the ``pair_id`` as::
 
     def pair_id_to_image_ids(pair_id):
         image_id2 = pair_id % 2147483647
         image_id1 = (pair_id - image_id2) / 2147483647
         return image_id1, image_id2
 
-The `pair_id` enables efficient database queries, as the matches tables may
+The ``pair_id`` enables efficient database queries, as the matches tables may
 contain several hundred millions of entries. This scheme limits the maximum
 number of images in a database to 2147483647 (maximum value of signed 32-bit
-integers), i.e. `image_id` must be smaller than 2147483647.
+integers), i.e. ``image_id`` must be smaller than 2147483647.
 
-The binary blobs in the matches tables are row-major `uint32` matrices, where
-the left column are zero-based indices into the features of `image_id1` and the
-second column into the features of `image_id2`. The column `cols` must be 2 and
-the `rows` column specifies the number of feature matches.
+The binary blobs in the matches tables are row-major ``uint32`` matrices, where
+the left column are zero-based indices into the features of ``image_id1`` and the
+second column into the features of ``image_id2``. The column ``cols`` must be 2 and
+the ``rows`` column specifies the number of feature matches.
 
-The F, E, H blobs in the `two_view_geometries` table are stored as 3x3 matrices
-in row-major `float64` format. The meaning of the `config` values are documented
-in the `src/estimators/two_view_geometry.h` source file.
+The F, E, H blobs in the ``two_view_geometries`` table are stored as 3x3 matrices
+in row-major ``float64`` format. The meaning of the ``config`` values are documented
+in the ``src/estimators/two_view_geometry.h`` source file.

_sources/faq.rst.txt

@@ -38,7 +38,7 @@ Share intrinsics
 
 COLMAP supports shared intrinsics for arbitrary groups of images and camera
 models. Images share the same intrinsics, if they refer to the same camera, as
-specified by the `camera_id` property in the database. You can add new cameras
+specified by the ``camera_id`` property in the database. You can add new cameras
 and set shared intrinsics in the database management tool. Please, refer to
 :ref:`Database Management <database-management>` for more information.
 

_sources/format.rst.txt

@@ -10,7 +10,7 @@ Binary File Format
 Note that all binary data is stored using little endian byte ordering. All x86
 processors are little endian and thus no special care has to be taken when
 reading COLMAP binary data on most platforms. The data can be most conveniently
-parsed using the C++ reconstruction API under `src/colmap/scene/reconstruction_io.h`
+parsed using the C++ reconstruction API under ``src/colmap/scene/reconstruction_io.h``
 or using the Python API provided by pycolmap.
 
 
@@ -22,10 +22,10 @@ Any variable name ending with ``*_idx`` should be considered as an ordered,
 contiguous zero-based index. In general, any variable name ending with ``*_id``
 should be considered as an unordered, non-contiguous identifier.
 
-For example, the unique identifiers of cameras (`CAMERA_ID`), images
-(`IMAGE_ID`), and 3D points (`POINT3D_ID`) are unordered and are most likely not
-contiguous. This also means that the maximum `POINT3D_ID` does not necessarily
-correspond to the number 3D points, since some `POINT3D_ID`'s are missing due to
+For example, the unique identifiers of cameras (``CAMERA_ID``), images
+(``IMAGE_ID``), and 3D points (``POINT3D_ID``) are unordered and are most likely not
+contiguous. This also means that the maximum ``POINT3D_ID`` does not necessarily
+correspond to the number 3D points, since some ``POINT3D_ID``'s are missing due to
 filtering during the reconstruction, etc.
 
 
@@ -36,18 +36,18 @@ Sparse Reconstruction
 By default, COLMAP uses a binary file format (machine-readable, fast) for
 storing sparse models. In addition, COLMAP provides the option to store the
 sparse models as text files (human-readable, slow). In both cases, the
-information is split into multiples files for the information about `rigs`,
-`cameras`, `frames`, `images`, and `points`. Any directory containing these
+information is split into multiples files for the information about ``rigs``,
+``cameras``, ``frames``, ``images``, and ``points``. Any directory containing these
 files constitutes a sparse model. The binary files have the file extension
-`.bin` and the text files the file extension `.txt`. Note that when loading a
+``.bin`` and the text files the file extension ``.txt``. Note that when loading a
 model from a directory which contains both binary and text files, COLMAP prefers
 the binary format.
 
-Note that older versions of COLMAP had no rig support and thus the `rigs` and
-`frames` files may be missing. The reconstruction I/O routines in COLMAP are
+Note that older versions of COLMAP had no rig support and thus the ``rigs`` and
+``frames`` files may be missing. The reconstruction I/O routines in COLMAP are
 fully backwards compatible in that models without these files can be read and
 trivial rigs and frames will be automatically initialized. Furthermore, newer
-output reconstructions' `cameras` and `images` files are fully compatible with
+output reconstructions' ``cameras`` and ``images`` files are fully compatible with
 old outputs.
 
 To export the currently selected model in the GUI, choose ``File > Export
@@ -56,7 +56,7 @@ model``. To export all reconstructed models in the current dataset, choose
 for convenience, the current project configuration for importing the model to
 COLMAP. To import the exported models, e.g., for visualization or to resume the
 reconstruction, choose ``File > Import model`` and select the folder containing
-the `cameras`, `images`, and `points3D` files.
+the ``cameras``, ``images``, and ``points3D`` files.
 
 To convert between the binary and text format in the GUI, you can load the model
 using ``File > Import model`` and then export the model in the desired output
@@ -76,7 +76,7 @@ Text Format
 -----------
 
 COLMAP exports the following three text files for every reconstructed model:
-`rigs.txt`, `cameras.txt`, `frames.txt`, `images.txt`, and `points3D.txt`.
+``rigs.txt``, ``cameras.txt``, ``frames.txt``, ``images.txt``, and ``points3D.txt``.
 Comments start with a leading "#" character and are ignored. The first comment
 lines briefly describe the format of the text files, as described in more
 detailed on this page.
@@ -114,9 +114,9 @@ Here, the dataset contains 3 cameras based using different distortion models
 with the same sensor dimensions (width: 3072, height: 2304). The length of
 parameters is variable and depends on the camera model. For the first camera,
 there are 3 parameters with a single focal length of 2559.81 pixels and a
-principal point at pixel location `(1536, 1152)`. The intrinsic parameters of a
+principal point at pixel location ``(1536, 1152)``. The intrinsic parameters of a
 camera can be shared by multiple images, which refer to cameras using the unique
-identifier `CAMERA_ID`.
+identifier ``CAMERA_ID``.
 
 
 frames.txt
@@ -152,8 +152,8 @@ dataset using two lines per image, e.g.::
 
 Here, the first two lines define the information of the first image, and so on.
 The reconstructed pose of an image is specified as the projection from world to
-the camera coordinate system of an image using a quaternion `(QW, QX, QY, QZ)`
-and a translation vector `(TX, TY, TZ)`. The quaternion is defined using the
+the camera coordinate system of an image using a quaternion ``(QW, QX, QY, QZ)``
+and a translation vector ``(TX, TY, TZ)``. The quaternion is defined using the
 Hamilton convention, which is, for example, also used by the Eigen library. The
 coordinates of the projection/camera center are given by ``-R^t * T``, where
 ``R^t`` is the inverse/transpose of the 3x3 rotation matrix composed from the
@@ -162,7 +162,7 @@ system of an image is defined in a way that the X axis points to the right, the
 Y axis to the bottom, and the Z axis to the front as seen from the image.
 
 Both images in the example above use the same camera model and share intrinsics
-(`CAMERA_ID = 1`). The image name is relative to the selected base image folder
+(``CAMERA_ID = 1``). The image name is relative to the selected base image folder
 of the project. The first image has 3 keypoints and the second image has 2
 keypoints, while the location of the keypoints is specified in pixel
 coordinates. Both images observe 2 3D points and note that the last keypoint of
@@ -183,8 +183,8 @@ dataset using one line per point, e.g.::
     63376 2.01848 0.108877 -0.0260841 102 209 250 1.73449 16 6519 15 7322 14 7212 8 3991
     63371 1.71102 0.28566 0.53475 245 251 249 0.612829 118 4140 117 4473
 
-Here, there are three reconstructed 3D points, where `POINT2D_IDX` defines the
-zero-based index of the keypoint in the `images.txt` file. The error is given in
+Here, there are three reconstructed 3D points, where ``POINT2D_IDX`` defines the
+zero-based index of the keypoint in the ``images.txt`` file. The error is given in
 pixels of reprojection error and is only updated after global bundle adjustment.
 
 
@@ -223,11 +223,11 @@ COLMAP uses the following workspace folder structure::
     +── run-colmap-geometric.sh
     +── run-colmap-photometric.sh
 
-Here, the `images` folder contains the undistorted images, the `sparse` folder
-contains the sparse reconstruction with undistorted cameras, the `stereo` folder
-contains the stereo reconstruction results, `point-cloud.ply` and `mesh.ply` are
-the results of the fusion and meshing procedure, and `run-colmap-geometric.sh`
-and `run-colmap-photometric.sh` contain example command-line usage to perform
+Here, the ``images`` folder contains the undistorted images, the ``sparse`` folder
+contains the sparse reconstruction with undistorted cameras, the ``stereo`` folder
+contains the stereo reconstruction results, ``point-cloud.ply`` and ``mesh.ply`` are
+the results of the fusion and meshing procedure, and ``run-colmap-geometric.sh``
+and ``run-colmap-photometric.sh`` contain example command-line usage to perform
 the dense reconstruction.
 
 
@@ -237,7 +237,7 @@ Depth and Normal Maps
 
 The depth maps are stored as mixed text and binary files. The text header
 defines the dimensions of the image in the format ``with&height&channels&``
-followed by row-major `float32` binary data. For depth maps ``channels=1`` and
+followed by row-major ``float32`` binary data. For depth maps ``channels=1`` and
 for normal maps ``channels=3``. The depth and normal maps can be conveniently
 read with Python using the functions in ``scripts/python/read_dense.py`` and
 with Matlab using the functions in ``scripts/matlab/read_depth_map.m`` and
@@ -251,7 +251,7 @@ Consistency Graphs
 The consistency graph defines, for all pixels in an image, the source images a
 pixel is consistent with. The graph is stored as a mixed text and binary file,
 while the text part is equivalent to the depth and normal maps and the binary
-part is a continuous list of `int32` values in the format
+part is a continuous list of ``int32`` values in the format
 ``<row><col><N><image_idx1>...<image_idxN>``. Here, ``(row, col)``  defines the
 location of the pixel in the image followed by a list of ``N`` image indices.
 The indices are specified w.r.t. the ordering in the ``images.txt`` file.

_sources/gui.rst.txt

@@ -5,8 +5,8 @@ Graphical User Interface
 
 The graphical user interface of COLMAP provides access to most of the available
 functionality and visualizes the reconstruction process in "real-time". To start
-the GUI, you can run the pre-built packages (Windows: `COLMAP.bat`, Mac:
-`COLMAP.app`), execute ``colmap gui`` if you installed COLMAP or execute
+the GUI, you can run the pre-built packages (Windows: ``COLMAP.bat``, Mac:
+``COLMAP.app``), execute ``colmap gui`` if you installed COLMAP or execute
 ``./src/colmap/exe/colmap gui`` from the CMake build folder. The GUI application
 requires an attached display with at least OpenGL 3.2 support. Registered images
 are visualized in red and reconstructed points in their average point color