![GitHub release (latest by date)](https://img.shields.io/github/v/release/PoseLib/PoseLib)
[![Conan Center](https://img.shields.io/conan/v/poselib)](https://conan.io/center/recipes/poselib)
![PyPI](https://img.shields.io/pypi/v/poselib)

# PoseLib
This library provides a collection of minimal solvers for camera pose estimation. The focus is on calibrated absolute pose estimation problems from different types of correspondences (e.g. point-point, point-line, line-point, line-line).

The goals of this project are to provide
* Fast and robust implementation of the current state-of-the-art solvers.
* Consistent calling interface between different solvers.
* Minimize dependencies, both external (currently only [Eigen](http://eigen.tuxfamily.org/)) and internal. Each solver is (mostly) stand-alone, making it easy to extract only a specific solver to integrate into other frameworks.
* Robust estimators (based on LO-RANSAC) that just works out-of-the-box for most cases.

# Robust Estimation and Non-linear Refinement
We provide robust estimators for the most common problems
* Absolute pose from points (and lines)
* Relative pose from points (Essential / Fundamental matrix, unknown shared focal length)
* Relative pose from points and monocular depth estimates.
* Homography
* Generalized relative pose

It is fairly straight-forward to implement robust estimators for other problems. See for example [absolute_pose.h](PoseLib/robust/estimators/absolute_pose.h). If you implement estimators for other problems, please consider submitting a pull-request.

In [robust.h](PoseLib/robust.h) we provide interfaces which normalizes the data, calls the RANSAC and runs a post-RANSAC non-linear refinement. It is also possible to directly call the individual components as well (see e.g. [ransac.h](PoseLib/robust/ransac.h), [bundle.h](PoseLib/robust/bundle.h), etc.). The RANSAC is straight-forward implementation of LO-RANSAC which generate hypothesis with minimal solvers and relies on non-linear refinement for refitting.

The robust estimator takes the following options.

General RANSAC options:
```c++
struct RansacOptions {
    size_t max_iterations = 100000;
    size_t min_iterations = 1000;
    double dyn_num_trials_mult = 3.0;
    double success_prob = 0.9999;
    unsigned long seed = 0;
    // If we should use PROSAC sampling. Assumes data is sorted
    bool progressive_sampling = false;
    size_t max_prosac_iterations = 100000;
    // Whether to treat the input 'best_model' as an initial model and score it before running the main RANSAC loop
    bool score_initial_model = false;
};
```
the non-linear refinement:
```c++
struct BundleOptions {
    size_t max_iterations = 100;
    enum LossType {
        TRIVIAL, TRUNCATED, HUBER, CAUCHY, TRUNCATED_CAUCHY, TRUNCATED_LE_ZACH
    } loss_type = LossType::CAUCHY;
    double loss_scale = 1.0;
    double gradient_tol = 1e-8;
    double step_tol = 1e-8;
    double initial_lambda = 1e-3;
    double min_lambda = 1e-10;
    double max_lambda = 1e10;
    bool verbose = false;
};
```

and the estimator specific options which contain the error thresholds and other settings. For more details and additional option structs (like `AbsolutePoseOptions` or `MonoDepthRelativePoseOptions`), see [types.h](PoseLib/types.h). 

For example, `RelativePoseOptions`:
```c++
struct RelativePoseOptions {
    RansacOptions ransac;
    BundleOptions bundle;

    double max_error = 1.0;      // Inlier threshold (in pixels)
    bool tangent_sampson = false; // Whether to use tangent Sampson error in LO
    bool real_focal_check = false; // Whether to use real focal length checking
};
```

Note that in [robust.h](PoseLib/robust.h) this is only used for the post-RANSAC refinement. For the relative pose estimators using monocular depth we recommend using `TRUNCATED_CAUCHY`.

In [bundle.h](PoseLib/robust/bundle.h) we provide non-linear refinement for different problems. Mainly minimizing reprojection error and Sampson error as these performed best in our internal evaluations. These are used in the LO-RANSAC to perform non-linear refitting. Most estimators directly minimize the MSAC score (using `loss_type = TRUNCATED` and `loss_scale = threshold`) over all input correspondences. In practice we found that this works quite well and avoids recursive LO where inliers are added in steps.

## Camera models
PoseLib use [COLMAP](https://colmap.github.io/cameras.html)-compatible camera models. These are defined in [colmap_models.h](PoseLib/misc/camera_models.h). Currently we only support
* SIMPLE_PINHOLE
* PINHOLE
* SIMPLE_RADIAL
* RADIAL
* OPENCV
* OPENCV_FISHEYE

but it is relatively straight-forward to add other models. If you do so please consider opening a pull-request. In contrast to COLMAP, we require analytical jacobians for the distortion mappings which make it a bit more work to port them.

The `Camera` struct currently contains `width`/`height` fields, however these are not used anywhere in the code-base and are provided simply to be consistent with COLMAP. The `Camera` class also provides the helper function `initialize_from_txt(str)` which initializes the camera from a line given by the `cameras.txt` file of a COLMAP reconstruction. 

The python bindings also expose the `poselib.Camera` class with `focal(), focal_x(), focal_y(), model_name(), prinicipal_point()` read-only methods and a read-write `params` property, but currently this is only used as a return type for some methods. To supply camera information to robust estimators you should use python `dicts` as shown below.

## Python bindings
The python bindings can be installed by running `pip install .`. The python bindings expose all minimal solvers, e.g. `poselib.p3p(x,X)`, as well as all robust estimators from [robust.h](PoseLib/robust.h). 

Examples of how the robust estimators can be called are
```python
camera = {'model': 'SIMPLE_PINHOLE', 'width': 1200, 'height': 800, 'params': [960, 600, 400]}

pose, info = poselib.estimate_absolute_pose(p2d, p3d, camera, {'max_error': 16.0}, {})
```
or
```python
F, info = poselib.estimate_fundamental(p2d_1, p2d_2, {'max_error': 0.75, 'progressive_sampling': True}, {})
mask_inl = info['inliers']

```

The return value `info` is a dict containing information about the robust estimation (inliers, iterations, etc). The last two options are dicts which describe the `RansacOptions` and `BundleOptions`. Ommited values are set to their default (see above), except for the `loss_scale` used for the Cauchy loss which is set to half of the threshold used in RANSAC (which seems to be a good heuristic). Dicts with the default options can be obtained as `opt = poselib.RansacOptions()` or `poselib.BundleOptions()`.



Some of the available estimators are listed below, check [pyposelib.cpp](pybind/pyposelib.cc) and [robust.h](PoseLib/robust.h) for more details. The table also shows which error threshold is used in the estimation (`max_error` or `max_errors`). All thresholds are given in pixels.

| Method | Arguments | Threshold |
| --- | --- | --- |
| <sub>`estimate_absolute_pose`</sub> | <sub> `(p2d, p3d, camera, ransac_opt, bundle_opt, initial_pose=None)`</sub> | <sub>`max_error` </sub> |
| <sub>`estimate_absolute_pose_pnpl`</sub> | <sub>`(p2d, p3d, l2d_1, l2d_2, l3d_1, l3d_2, camera, ransac_opt, bundle_opt, initial_pose=None)` </sub> | <sub>`max_errors[0]` (points), `max_errors[1]` (lines) |
| <sub>`estimate_generalized_absolute_pose` | <sub>`(p2ds, p3ds, camera_ext, cameras, ransac_opt, bundle_opt, initial_pose=None)`</sub> | <sub>`max_error`</sub> |
| <sub>`estimate_relative_pose`</sub> | <sub>`(x1, x2, camera1, camera2, ransac_opt, bundle_opt, initial_pose=None)`</sub> | <sub>`max_error` </sub>|
| <sub>`estimate_shared_focal_relative_pose`</sub> | <sub>`(x1, x2, pp, ransac_opt, bundle_opt, initial_image_pair=None)`</sub> | <sub>`max_error` </sub>|
| <sub>`estimate_fundamental`</sub> | <sub>`(x1, x2, ransac_opt, bundle_opt, initial_F=None)`</sub> | <sub>`max_error`</sub> |
| <sub>`estimate_homography`</sub> | <sub>`(x1, x2, ransac_opt, bundle_opt, initial_H=None)`</sub> | <sub>`max_error`</sub> |
| <sub>`estimate_monodepth_relative_pose`</sub> | <sub>`(x1, x2, d1, d2, camera1, camera2, ransac_opt, bundle_opt)`</sub> | <sub>`max_errors[0]` (reproj), `max_errors[1]` (epipolar)</sub> |
| <sub>`estimate_monodepth_shared_focal_relative_pose`</sub> | <sub>`(x1, x2, d1, d2, ransac_opt, bundle_opt)`</sub> | <sub>`max_errors[0]` (reproj), `max_errors[1]` (epipolar)</sub> |
| <sub>`estimate_monodepth_varying_focal_relative_pose`</sub> | <sub>`(x1, x2, d1, d2, ransac_opt, bundle_opt)`</sub> | <sub>`max_errors[0]` (reproj), `max_errors[1]` (epipolar)</sub> |

### Storing poses and estimated camera parameters
To handle poses and cameras we provide the following classes: 

- `CameraPose`: This class is the return type for the most of the methods. While the class internally represent the pose with `q` and `t`, it also exposes `R` (3x3) and `Rt` (3x4) which are read/write, i.e. you can do `pose.R = Rnew` and it will update the underlying quaternion `q`.
- `MonoDepthTwoViewGeometry`: This class is the return type for the calibrated monocular depth solvers and estimators. It holds CameraPose as `pose`, the relative `scale` of the two depths and their shifts `shift1`, `shift2`.
- `Image`: Following COLMAP, this class stores information about the camera (`image.camera`) and its pose (`image.pose`) used to take an image.
- `ImagePair`: This class holds information about two cameras (`image_pair.camera1`, `image_pair.camera2`) and their relative pose (`image_pair.pose`). This class is used as the return type for the `estimate_shared_focal_relative_pose` robust estimator.
- `MonoDepthImagePair`: Similar to `ImagePair`, but instead of holding pose directly it holds `MonoDepthTwoViewGeometry` as `geometry`. This class is used for the uncalibrated relative pose solvers/estimators using points and monocular depth estimates.
- `ProjectiveImagePair`: This class is used for F + radial distortion solvers. It stores information about the cameras (`image.camera1`, `image.camera2`) which usually contain only the distortion parameters. The class also stores the fundamental matrix `F` which contains information about the pose and other intrinsics.

All of these are also exposed via python bindings as: `poselib.CameraPose, poselib.Image, poselib.ImagePair`.

### Benchmarking the robust estimators
To sanity-check the robust estimators we benchmark against the LO-RANSAC implementation from [pycolmap](https://github.com/colmap/pycolmap).
    
<a href="https://user-images.githubusercontent.com/48490995/149815304-b3c1049a-ee64-4c14-be60-d4930535a3e7.png"><img src="https://user-images.githubusercontent.com/48490995/149815304-b3c1049a-ee64-4c14-be60-d4930535a3e7.png" width="75%"></a>
    
For all of the metrics higher is better (except for runtime).

# Minimal Solvers
## Naming convention
For the solver names we use a slightly non-standard notation where we denote the solver as

<pre>
p<b><i>X</i></b>p<b><i>Y</i></b>pl<b><i>Z</i></b>lp<b><i>W</i></b>ll
</pre>

where the number of correspondences required is given by
* <b><i>X</i></b>p - 2D point to 3D point,
* <b><i>Y</i></b>pl - 2D point to 3D line,
* <b><i>Z</i></b>lp - 2D line to 3D point,
* <b><i>W</i></b>ll - 2D line to 3D line.

The prefix with `u` is for upright solvers and  `g` for generalized camera solvers. Solvers that estimate focal length have the postfix with `f` and similarly `s` for solvers that estimate scale.

## Calling conventions
All solvers return their solutions as a vector of `CameraPose` structs, which defined as
```c++
struct CameraPose {
   Eigen::Vector4d q;
   Eigen::Vector3d t;
};
```
where the rotation is representation as a quaternion `q` and the convention is that `[R t]` maps from the world coordinate system into the camera coordinate system.


For <b>2D point to 3D point</b> correspondences, the image points are represented as unit-length bearings vectors. The returned camera poses `(R,t)` then satisfies (for some `lambda`)
```c++
  lambda * x[i] = R * X[i] + t
```
where `x[i]` is the 2D point and `X[i]` is the 3D point.
<b>Note</b> that only the P3P solver filters solutions with negative `lambda`.

Solvers that use point-to-point constraints take one vector with bearing vectors `x` and one vector with the corresponding 3D points `X`, e.g. for the P3P solver the function declaration is

```c++
int p3p(const std::vector<Eigen::Vector3d> &x,
        const std::vector<Eigen::Vector3d> &X,
        std::vector<CameraPose> *output);
```
Each solver returns the number of real solutions found.

For constraints with <b>2D lines</b>, the lines are represented in homogeneous coordinates. In the case of 2D line to 3D point constraints, the returned camera poses then satisfies
```c++
  l[i].transpose() * (R * X[i] + t) = 0
```
where `l[i]` is the line and  `X[i]` is the 3D point.

For constraints with <b>3D lines</b>, the lines are represented by a 3D point `X` and a bearing vector `V`. In the case of 2D point to 3D point constraints
```c++
  lambda * x[i] = R * (X[i] + mu * V[i]) + t
```
for some values of `lambda` and `mu`. Similarly, for line to line constraints we have
```c++
  l[i].transpose() * (R * (X[i] + mu * V[i]) + t) = 0
```
### Generalized Cameras
For generalized cameras we represent the image rays similarly to the 3D lines above, with an offset `p` and a bearing vector `x`. For example, in the case of point-to-point correspondences we have
```c++
p[i] + lambda * x[i] = R * X[i] + t
```
In the case of unknown scale we also estimate `alpha` such that
```c++
alpha * p[i] + lambda * x[i] = R * X[i] + t
```
For example, the generalized pose and scale solver (from four points) has the following signature
```c++
 int gp4ps(const std::vector<Eigen::Vector3d> &p, const std::vector<Eigen::Vector3d> &x,
              const std::vector<Eigen::Vector3d> &X, std::vector<CameraPose> *output);
```

### Upright Solvers
For the upright solvers it assumed that the rotation is around the y-axis, i.e.
```c++
R = [a 0 -b; 0 1 0; b 0 a] 
```
To use these solvers it necessary to pre-rotate the input such that this is satisfied.

### Solvers Using Monocular Depth
MonoDepth solvers assume that an estimate of depths (using a neural network) is available for each point correspondence. These solvers require the estimated depths to be passed to the solvers along with the point correspondences.   

Currently, PoseLib includes only relative pose solvers with known monocular depth estimates `d1, d2` and point correspondences `x1, x2`. The MDE estimators are usually trained to be affine-invariant or scale invariant. Therefore, solvers output the relative scale and in the case of the calibrated variant also the shifts along with the relative pose. It is then possible to estimate the 3D points corresponding to the points. 
```c++
X1[i] = (d1[i] + shift_1) * K1_inv * x1[i].homogeneous().eval();
X2[i] = scale * (d2[i] + shift_2) * K2_inv * x2[i].homogeneous().eval();

// X1[i] in coordinate frame of the second camera 
X1_2[i] = R * X1[i] + t;
// X2[i] in coordinate frame of the first camera
X2_1[i] = R.transpose() * (X2[i] - t);
```  
 
## Implemented solvers
The following solvers are currently implemented.

### Absolute Pose
| Solver | Point-Point | Point-Line | Line-Point | Line-Line | Upright | Generalized | Approx. runtime | Max. solutions | Comment |
| --- | :---: | :---: | :---: | :---: | :---: | :---: | :---: | :---: | --- |
| `p3p` | 3 | 0 | 0| 0|  |  | 250 ns | 4 | Ding et al., (CVPR23) |
| `gp3p` | 3 | 0 | 0| 0|  | :heavy_check_mark:  | 1.6 us | 8 | Kukelova et al., E3Q3 (CVPR16) |
| `gp4ps` | 4 | 0 | 0| 0|  | :heavy_check_mark: | 1.8 us | 8 | Unknown scale.<br> Kukelova et al., E3Q3 (CVPR16)<br>Camposeco et al.(ECCV16) |
| `p4pf` | 4 | 0 | 0| 0|  |  | 2.3 us | 8 | Unknown focal length.<br> Kukelova et al., E3Q3 (CVPR16) |
| `p2p2pl` | 2 | 2 | 0| 0|  |  | 30 us | 16 | Josephson et al. (CVPR07) |
| `p6lp` | 0 | 0 | 6|  0| |  | 1.8 us | 8 | Kukelova et al., E3Q3 (CVPR16)  |
| `p5lp_radial` | 0 | 0 | 5|  0| |  | 1 us | 4 | Kukelova et al., (ICCV13)  |
| `p2p1ll` | 2 | 0 | 0 |  1| |  | 1.6 us | 8 | Kukelova et al., E3Q3 (CVPR16), Zhou et al. (ACCV18)  |
| `p1p2ll` | 1 | 0 | 0 |  2| |  | 1.7 us | 8 | Kukelova et al., E3Q3 (CVPR16), Zhou et al. (ACCV18)  |
| `p3ll` | 0 | 0 | 0 |  3| |  | 1.8 us | 8 | Kukelova et al., E3Q3 (CVPR16), Zhou et al. (ACCV18)  |
| `up2p` | 2 | 0 | 0| 0| :heavy_check_mark: |  | 65 ns | 2 | Kukelova et al. (ACCV10) |
| `ugp2p` | 2 | 0 | 0| 0| :heavy_check_mark: | :heavy_check_mark: | 65 ns | 2 | Adapted from Kukelova et al. (ACCV10)   |
| `ugp3ps` | 3 | 0 | 0| 0| :heavy_check_mark: | :heavy_check_mark: | 390 ns | 2 | Unknown scale. Adapted from Kukelova et al. (ACCV10)  |
| `up1p2pl` | 1 | 2 | 0| 0| :heavy_check_mark: |  | 370 ns | 4 |  |
| `up4pl` | 0 | 4 | 0| 0| :heavy_check_mark: |  | 1.4 us | 8 | Sweeney et al. (3DV14) |
| `ugp4pl` | 0 | 4 | 0| 0| :heavy_check_mark: | :heavy_check_mark: | 1.4 us | 8 | Sweeney et al. (3DV14) |


### Relative Pose
| Solver | Point-Point | Upright | Planar | Generalized | MonoDepth | Approx. runtime | Max. solutions | Comment |
| --- | :---: | :---: | :---: | :---: | :---: | :---: | :---: | --- |
| `relpose_5pt` | 5 | | | | | 5.5 us | 10 | Nister (PAMI 2004) |
| `relpose_8pt` | 8+ | | | | | 2.2+ us | 1 |  |
| `relpose_upright_3pt` | 3 | :heavy_check_mark: | | | | 210 ns | 4 | Ding et al., (CVPR23)  |
| `gen_relpose_upright_4pt` | 4 | :heavy_check_mark: | | :heavy_check_mark:  | | 1.2 us | 6 | Sweeney et al. (3DV14)  |
| `relpose_upright_planar_2pt` | 2 | :heavy_check_mark: | :heavy_check_mark: | | | 120 ns | 2 | Choi and Kim (IVC 2018)  |
| `relpose_upright_planar_3pt` | 3 | :heavy_check_mark: | :heavy_check_mark: | | | 300 ns | 1 |  Choi and Kim (IVC 2018) |
| `gen_relpose_5p1pt` | 5+1 |  | | :heavy_check_mark: | | 5.5 us | 10 | E + 1pt to fix scale  |
| `relpose_6pt_shared_focal` | 6 |  | | | | 33 us | 15 | Stewénius et al. (IVC 2008) |
| `relpose_k2Fk1_10pt` | 10 |  | | | | 15 us | 10 | Kukelova et al. (ICCV 2015) |
| `relpose_kFk_9pt` | 9 |  | | | | 45 us | 6 | Tzamos et al. (ECCVW 2024) |
| `relpose_monodepth_3pt` | 3 |  | | | :heavy_check_mark: | 870ns | 4 | Ding et al. (ICCV 2025) |
| `relpose_monodepth_3pt_shared_focal` | 3 |  | | | :heavy_check_mark: | 2.4 us | 4 | Ding et al. (ICCV 2025) |
| `relpose_monodepth_3pt_varying_focal` | 3 |  | | | :heavy_check_mark: | 280 ns | 1 | Ding et al. (ICCV 2025) |


## Decompositions

Poselib also provides methods and python bindings for decomposing fundamental matrices to obtain the focal lengths of the cameras and a method for decomposition of homography to poses and plane normals.

| Method | Arguments | Output | Comment |
|---|:---:|:---:|:---:|
| <sub>`focals_from_fundamental` </sub> | <sub>`(F, pp1, pp2)`</sub> | <sub>`(cam1, cam2)`</sub> | Bougnoux (ICCV 1998) |
| <sub>`focals_from_fundamental_iterative`</sub> | <sub>`(F, cam1_prior, cam2_prior, max_iters = 50, weights = {5e-4, 1.0, 5e-4, 1.0})`</sub> | <sub>`(cam1, cam2, iters)`</sub> | Kocur et al. (CVPR 2024) |
| <sub>`motion_from_homography`</sub> | <sub>`(H)`</sub> | <sub>`(poses, normals)`</sub> | Adapted from Ma et al. (Springer 2004) |

To obtain the focal lengths from the camera object you can use `focal = cam.focal()`. Note that both focal length methods can produce very inaccurate results and fail often such that the output focal lengths can be NaNs or negative numbers. If you need to estimate a focal length shared by both cameras (e.g. the same camera in both views) you should use `estimate_shared_focal_relative_pose`.

If you use H obtained using correspondences in image coordinates from two cameras you need to use `K2_inv * H * K1` as input to `motion_from_homography`.

## How to compile?

Getting the code:

    > git clone --recursive https://github.com/vlarsson/PoseLib.git
    > cd PoseLib

Example of a local installation:

    > mkdir _build && cd _build
    > cmake -DCMAKE_INSTALL_PREFIX=../_install ..
    > cmake --build . --target install -j 8
      (equivalent to  'make install -j8' in linux)

Installed files:

    > tree ../_install
      .
      ├── bin
      │   └── benchmark
      ├── include
      │   └── PoseLib
      │       ├── solvers/gp3p.h
      │       ├──  ...
      │       ├── poselib.h          <==  Library header (includes all the rest)
      │       ├──  ...
      │       └── version.h
      └── lib
          ├── cmake
          │   └── PoseLib
          │       ├── PoseLibConfig.cmake
          │       ├── PoseLibConfigVersion.cmake
          │       ├── PoseLibTargets.cmake
          │       └── PoseLibTargets-release.cmake
          └── libPoseLib.a

Uninstall library:

    > make uninstall

## Installation

### Installing PoseLib using Conan

You can install pre-built binaries for PoseLib or build it from source using
[Conan](https://conan.io/). Use the following command:

```bash
conan install --requires="poselib/[*]" --build=missing
```

The PoseLib Conan recipe is kept up to date by Conan maintainers and community
contributors. If the version is out of date, please
[create an issue or pull request](https://github.com/conan-io/conan-center-index)
on the ConanCenterIndex repository.

## Benchmark

Conditional compilation of the `solver_benchmark` binary is controlled by `WITH_BENCHMARK` option. Default is OFF (without benchmark).

Add `-DWITH_BENCHMARK=ON` to cmake to activate.

    > cmake -DWITH_BENCHMARK=ON ..



## Use library (as dependency) in an external project.

    cmake_minimum_required(VERSION 3.13)
    project(Foo)

    find_package(PoseLib REQUIRED)

    add_executable(foo foo.cpp)
    target_link_libraries(foo PRIVATE PoseLib::PoseLib)


## Citing
If you are using the library for (scientific) publications, please cite the following source:
```
@misc{PoseLib,
  title = {{PoseLib - Minimal Solvers for Camera Pose Estimation}},
  author = {Viktor Larsson and contributors},
  URL = {https://github.com/vlarsson/PoseLib},
  year = {2020}
}
```
Please cite also the original publications of the different methods (see table above).

## Changelog

2.0.5 - Aug. 2025
* Add Conan install section in README by @uilianries in https://github.com/PoseLib/PoseLib/pull/106
* Add some badges to README.md. by @pablospe in https://github.com/PoseLib/PoseLib/pull/107
* Move objects to avoid copy in camera constructors by @ahojnnes in https://github.com/PoseLib/PoseLib/pull/114
* Change default -march=native to be disabled by @vlarsson in https://github.com/PoseLib/PoseLib/pull/115
* Refined P3P solver, and a new implementation for rel_pose_upright_3pt by @yaqding in https://github.com/PoseLib/PoseLib/pull/93
* Bugfix in default camera for shared focal relpose by @kocurvik in https://github.com/PoseLib/PoseLib/pull/120
* Add numpy as a dependency for the python wheel by @theartful in https://github.com/PoseLib/PoseLib/pull/125
* Fix pybind11 calling overhead by @vlarsson in https://github.com/PoseLib/PoseLib/pull/116
* Wrapper for relative pose with non-upright gravity by @B1ueber2y in https://github.com/PoseLib/PoseLib/pull/124
* Add overloaded wrapper methods for passing poselib::Camera instead of py::dict. by @ghanning in https://github.com/PoseLib/PoseLib/pull/127
* Added H decomposition by @kocurvik in https://github.com/PoseLib/PoseLib/pull/121
* Release the GIL whenever possible to allow multithreading from python by @theartful in https://github.com/PoseLib/PoseLib/pull/123
* Pybind reference fixes by @ghanning in https://github.com/PoseLib/PoseLib/pull/128
* Restore default arguments for `ransac_opt` and `bundle_opt` by @ghanning in https://github.com/PoseLib/PoseLib/pull/135
* Add option to pass initial model to robust solvers. by @ghanning in https://github.com/PoseLib/PoseLib/pull/136
* Added `FULL_OPENCV` camera model from `dev` by @VladislavZavadskyy in https://github.com/PoseLib/PoseLib/pull/138
* faster up1p2pl solver by @yaqding in https://github.com/PoseLib/PoseLib/pull/139
* New homography solver by @yaqding in https://github.com/PoseLib/PoseLib/pull/141
* Scale cauchy loss to approximate r^2 in inlier region by @theartful in https://github.com/PoseLib/PoseLib/pull/143
* Remove gcc flags when using msvc for building pyposelib by @theartful in https://github.com/PoseLib/PoseLib/pull/132
* Symmetric homography transfer error in local optimization by @yaqding in https://github.com/PoseLib/PoseLib/pull/144
* Updated Python packaging + CI by @Parskatt in https://github.com/PoseLib/PoseLib/pull/146

2.0.4 - Aug. 2024
* Added implementation of OpenCVFisheye camera model
* Bumped pybind11 version which seems to fix some crashes
* Added cmake option to disable -march=native

2.0.3 - Jul. 2024
* Added decomposition methods for estimation of focal lengths from fundamental matrices

2.0.2 - Apr. 2024
* Added solver and robust estimator for 6p relative pose with unknown shared focal length
* Added Image, ImagePair classes with python bindings
* Exposed Camera via python bindings

2.0.1 - Sep. 2023
* Refactor pybind such that `pip install .` works. Moved pybind11 to submodule.
* C++ alignment fixes. Should now work with Eigen 3.3 and the header should be COLMAP compatible.

2.0 - Jan. 2022
* Added robust estimators (LO-RANSAC) and non-linear refinement
* Refactored CameraPose to use quaternion instead 3x3 matrix. Removed alpha.
* Implemented TR-IRLS  method from Le and Zach (3DV 2021)
* Restructured pybind11 interface
* Added support for PROSAC sampling
* Many minor fixes and improvements....

1.0 - Jan. 2020
* Initial release

## License
PoseLib is licensed under the BSD 3-Clause license. Please see [License](https://github.com/vlarsson/PoseLib/blob/master/LICENSE) for details.

## Acknowledgements
The RANSAC implementation is heavily inspired by [RansacLib](https://github.com/tsattler/RansacLib) from Torsten Sattler.
