-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Camera Optimizer has different pose adjustments when applied to Raybundle and Camera. #3073
Comments
Thanks for sharing the knowledge. I think the correction transform Think about the case when we have pose estimate of a sensor rig that contains two cameras. The two cameras have their own pose estimates subject to their fixed extrinsics @oseiskar Just want to learn your thoughts on this? |
@jb-ye I did not actually check this in detail in e8e05ff, and just kept the multiplication order from the original 3DGS PR I agree with you that it would be better to multiply camera-to-world from the left since that would also work for multi-camera rigs: If you have a single adjusment matrix for all cameras in the rig, the multiplying with that from the left would work for adjusting the pose of the rig correctly. However, as long as there are no such rig constraints but all cameras are optimized independently, then all of the versions discussed in this thread are OK. They are just different ways to parametrize adjustments to a SE(3) pose. The main problem in the current version seems to be that the NeRF (ray bundle) and 3DGS use different interpretations for the parameters, which is not nice since it breaks in cases like @nexuslrf 's test. It might be safest to fix the 3DGS version to match the NeRF one, since at least for 3DGS, all versions should be fine, but for NeRFs, there could be more performance implications (just guessing here, though). If support for multi-camera setups is added, then both version should probably be fixed to use the multiply-from-the-left form. |
Thanks everyone for the discussion! Some quick thoughts. The reason for the original Assuming this is true, one suggestion is to keep the current behavior for NeRFs, but match the splatfacto behavior for consistency and document it better: it's a separate rotation around the camera frame origin + translation in world coordinates.1
If we want to switch to a single rigid transform, between left- vs right- multiplied my very weak personal bias is actually for right-multiplied, mostly because it seems like the standard in packages like Ceres and gtsam. I don't find the multi-sensor rig case super convincing, since (a) you have to write custom code anyways and (b) right-multiplication is more convenient for the complementary case where you have good global rig poses but don't trust per-sensor calibrations relative to the rig. Footnotes |
I would like to add that being able to handle all relevant cases with a single rigid transform, which is either left or right multiplication is not a very sustainable goal. In a system that can deal with cases such as multi-camera rigs and possibly extrinsic calibration correction, you will anyway end up simultaneously transforming the poses from both left (tune the pose of the rig) and right (fixed or adjustable transform within the local rig coordinates) and some of these transforms will be shared between multiple cameras. ... and, without multi-camera support, it does not really matter so I also support this:
|
Also allow exporting Nerfacto-optimized poses. Fixes nerfstudio-project#3073.
Also allow exporting Nerfacto-optimized poses. Fixes nerfstudio-project#3073.
Also allow exporting Nerfacto-optimized poses. Fixes nerfstudio-project#3073. Second revision where the rotation and translation parts are handled separately.
Also allow exporting Nerfacto-optimized poses. Fixes nerfstudio-project#3073. Second revision where the rotation and translation parts are handled separately.
Hi developers,
I found a pretty tricky computation inconsistency issue on
camera_optimizer
'sapply_to_*
functions:nerfstudio/nerfstudio/cameras/camera_optimizers.py
Lines 148 to 168 in babf577
The rotation and translation shown in the above two functions are completely different.
Assume the original pose is
[R, t]
, and pose adjustment inCameraOptimizer
is[dR, dt]
apply_to_raybundle
: simply translates theorigins
(t+dt
), and rotates the raydirections
(dR @ R @ ray_vec
)apply_to_camera
: new camera is[R@dR, t+R@dt]
, when using this new camera to generate raysorigins
will bet+R@dt
,directions
transformation will beR @ dR @ ray_vec
.I initially wanted to evaluate the quality of camera optimization of a trained NeRF model by applying this
apply_to_camera
function but found such a computation mismatch. I guess these functions would also be confusing for other users (for sure 🤣It would be better in the future version to add some caution notes and an option to switch to different forms of pose adjustments.
For example,
The text was updated successfully, but these errors were encountered: