Thanks, the reordering of the methods is a bit unrelated to the actual change. I don't have super strong opinions but I actually ordered it intentionally as rigs before cameras to be consistent with frames before images. What's the rationale for swapping cameras and rigs?

This aligns with the ordering of initialization, as in here: https://github.com/colmap/colmap/blob/main/src/colmap/scene/reconstruction.cc#L134. This was because we wanted to check whether each camera in the rig exists in the reconstruction: #3564

Thanks, the reordering of the methods is a bit unrelated to the actual change. I don't have super strong opinions but I actually ordered it intentionally as rigs before cameras to be consistent with frames before images. What's the rationale for swapping cameras and rigs?

This aligns with the ordering of initialization, as in here: https://github.com/colmap/colmap/blob/main/src/colmap/scene/reconstruction.cc#L134. This was because we wanted to check whether each camera in the rig exists in the reconstruction: #3564

Alternatively, we can also keep the previous order but add a rig ptr inside the camera class, and reorder initialization back to rigs -> cameras -> frames -> images, to be consistent with the frames and images.

This will however, lose the possibility to check whether each camera in the rig exists in the reconstruction, similar to the issue that we cannot check whether each image in the frame exists in the reconstruction, as frames must be inserted before images due to the presence of frame ptr in the images. After all we can only check one direction because we support independent AddCamera and AddImage regardless of rigs and frames.

Thanks for the explanation. I don't think it matters too much and I am also fine with changing it to your proposal, if you feel strongly about it. My reasoning for the ordering was to first list rigs and then all its sensors (with cameras just being one of them and more to be added later). Equivalently, first list frames and then all its data (with images just being one of them and more to be added later).

Thanks for the explanation. I don't think it matters too much and I am also fine with changing it to your proposal, if you feel strongly about it. My reasoning for the ordering was to first list rigs and then all its sensors (with cameras just being one of them and more to be added later). Equivalently, first list frames and then all its data (with images just being one of them and more to be added later).

Thanks. The reasoning you mentioned also makes sense to me. I agree that in the end it does not matter much. Feel free to ask if we want to revert the ordering before merging (I can do it quickly). Otherwise I think we could move forward, as it is blocking the downstream hloc fix : )

If it's not a big issue, I suggest containing this PR to the changes in the title and undo the reordering.

If it's not a big issue, I suggest containing this PR to the changes in the title and undo the reordering.

Done. Thanks!

Thank you.