…camera rays (#3159)
This is the first in a series of PRs to support cameras with >180deg FOV
(including spherical cameras). This PR should result in no behavioral
change other than changes up to numerical precision.

Currently, if we manage to initialize from one pair but get stuck after
a few images and none of the other pairs satisfy the initialization
thresholds, then we never try to initialize from a relaxed set of
thresholds anymore for the remaining images, even though there is a high
chance to succeed. In addition, we unnecessarily tried the same pairs
redundantly for the same initialization constraints. This should result
in more complete reconstruction results and faster initialization.

…#3167)
This was a big confusion. I added some comments to explain why the fix
in #3155 was correct.
In the end its because that in COLMAP we use the left convention, while
in GTSAM and its reference paper here https://arxiv.org/pdf/1812.01537
the right convention was employed.
This is also in preparation for another PR on propagating relative pose
covariance in COLMAP (with left convention) with cross-pose correlation
available. This will encode the fact that the close image has lower
relative pose covariance and does not get affected by Gauge ambiguity.

I found that some of my collaborators aren't aware of the pre-built
Docker image. I think it would be helpful to mention it somewhere on the
documentation's installation page.

A/B comparison against main branch. Changes mostly up to numerical noise
except for "meadow" as the usual outlier.
```
I20250217 19:45:49.373275 1782301 compare.py:main:58] Results A - B:
=====scenes===== ======AUC @ X deg (%)====== ===images=== =components=
                  0.5    1.0    5.0    10.0     reg   all  num largest
==============================eth3d=dslr==============================
botanical_garden  -0.03  -0.02  -0.00  -0.00      0     0    0       0
boulders          -0.01  -0.00  -0.00  -0.00      0     0    0       0
bridge             0.00   0.00   0.00   0.00      0     0    0       0
courtyard          0.01   0.00   0.00   0.00      0     0    0       0
delivery_area      0.00   0.00   0.00   0.00      0     0    0       0
door              -0.00  -0.00  -0.00  -0.00      0     0    0       0
electro           -0.03  -0.00   0.00   0.00      0     0    0       0
exhibition_hall    0.01  -0.02  -0.00  -0.00      0     0    0       0
facade            -0.01  -0.01  -0.00  -0.00      0     0    0       0
kicker            -0.04  -0.02  -0.00  -0.00      0     0    0       0
lecture_room       0.00  -0.00  -0.00  -0.00      0     0    0       0
living_room        0.03   0.02   0.00   0.00      0     0    0       0
lounge            -0.03  -0.01  -0.00  -0.00      0     0    0       0
meadow            -3.93  -2.52  -0.50  -0.25      0     0    0       0
observatory        0.00   0.00   0.00   0.00      0     0    0       0
office            -0.03  -0.03  -0.01  -0.01      0     0    0       0
old_computer      -0.68  -0.35  -0.08  -0.04      0     0    0       0
pipes              1.50   0.95   0.19   0.09      0     0    0       0
playground        -0.03  -0.02  -0.00  -0.00      0     0    0       0
relief             0.03   0.02   0.00   0.00      0     0    0       0
relief_2          -0.00  -0.00  -0.00  -0.00      0     0    0       0
statue             0.00   0.00   0.00   0.00      0     0    0       0
terrace           -0.04  -0.02  -0.00  -0.00      0     0    0       0
terrace_2         -0.00  -0.00  -0.00  -0.00      0     0    0       0
terrains           0.00   0.00  -0.00  -0.00      0     0    0       0
----------------------------------------------------------------------
overall           -0.06  -0.03  -0.01  -0.00      0     0    0       0
----------------------------------------------------------------------
average           -0.13  -0.08  -0.02  -0.01      0     0    0       0
```

…face (#3170)
Now the name is too long. Creating this PR to initiate the thread.
---------
Co-authored-by: Johannes Schönberger <jsch@demuc.de>

Towards supporting spherical / large FOV cameras for which a different
logic will have to be implemented than for perspective projection
models. The logic is now specialized and localized within the camera
model and the user just knows about valid or invalid projections. This
can also be used to more robustly deal with numerical issues in
distortion computation (as we have for some of the fisheye models).
The next PRs will do the equivalent for CamFromImg to return camera rays
rather than image points as well as remove redundant
"HasPointPositiveDepth/Cheirality" checks.
---------
Co-authored-by: Paul-Edouard Sarlin <15985472+sarlinpe@users.noreply.github.com>

…h/update