Why this change? This step in isolation feels a bit backwards without understanding the context. In particular, the previous approach of storing all info related to a view pair in a single structure looks superior to me as opposed to storing it in separate/redundant maps?

Why this change? This step in isolation feels a bit backwards without understanding the context. In particular, the previous approach of storing all info related to a view pair in a single structure looks superior to me as opposed to storing it in separate/redundant maps?

The goal is to replace ImagePair with TwoViewGeometry, which can enable a lot of consolidation in the two view geometry part.

Or, alternative, do we want to add a weight field in TwoViewGeometry? It also feels not ideal. The weight is actually only used in rotation averaging, and is disabled by default.

If it's disabled by default then it sounds like we should maybe just get rid of it?

If it's disabled by default then it sounds like we should maybe just get rid of it?

I agree, unless there were some exotic use cases for this weight field. Was it only used in the testing process? Dropping it would also mean removing this field in the CLI: https://github.com/colmap/glomap/blob/main/glomap/exe/rotation_averager.cc#L30

I suggest removing it. I think this was only used for testing in the past. If we really need it again, then it's easy enough to bring back. Let's use the luxury of this initial import of the code to clean up and simplify as much as possible.

I suggest removing it. I think this was only used for testing in the past. If we really need it again, then it's easy enough to bring back. Let's use the luxury of this initial import of the code to clean up and simplify as much as possible.

Done. PTAL : )