Skip to content
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

bugfix: handle multiple camera types in a single batch #3415

Merged
merged 3 commits into from
Sep 10, 2024

Conversation

decrispell
Copy link
Contributor

Training with mixed batches of camera types seems to be broken. The camera types are looped over, but the same type will trigger the if/else each time through the loop in its current form, leaving uninitialized rays for the other camera types.

This MR fixes that, enabling support for mixed batches of rays. My guess is this was the original intent of the code.

@jb-ye jb-ye requested a review from cvachha September 5, 2024 17:57
@jb-ye
Copy link
Collaborator

jb-ye commented Sep 5, 2024

The original code does seem buggy to me. @cvachha Could you take a look at this PR fix?

@cvachha
Copy link
Contributor

cvachha commented Sep 7, 2024

Thanks for the fix! I think this code change looks good, however I am unable to validate it working on multi-camera input and am not familiar with the initial reason why that loop was originally written that way. I am requesting another reviewer to take a look.

@cvachha cvachha requested a review from brentyi September 7, 2024 21:21
@@ -778,15 +778,15 @@ def _compute_rays_for_vr180(

return vr180_origins, directions_stack

for cam in cam_types:
if CameraType.PERSPECTIVE.value in cam_types:
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As an alternative fix, would it make sense to:

  • Remove the for cam in cam_types
  • De-dent all of the contents
  • Change all of the if to elif?

I went through this file history and it seems like that's how these conditions were originally set up:

if CameraType.PERSPECTIVE.value in cam_types:
mask = (self.camera_type[true_indices] == CameraType.PERSPECTIVE.value).squeeze(-1) # (num_rays)
mask = torch.stack([mask, mask, mask], dim=0)
directions_stack[..., 0][mask] = torch.masked_select(coord_stack[..., 0], mask).float()
directions_stack[..., 1][mask] = torch.masked_select(coord_stack[..., 1], mask).float()
directions_stack[..., 2][mask] = -1.0
if CameraType.FISHEYE.value in cam_types:
mask = (self.camera_type[true_indices] == CameraType.FISHEYE.value).squeeze(-1) # (num_rays)
mask = torch.stack([mask, mask, mask], dim=0)
theta = torch.sqrt(torch.sum(coord_stack**2, dim=-1))
theta = torch.clip(theta, 0.0, math.pi)
sin_theta = torch.sin(theta)
directions_stack[..., 0][mask] = torch.masked_select(coord_stack[..., 0] * sin_theta / theta, mask).float()
directions_stack[..., 1][mask] = torch.masked_select(coord_stack[..., 1] * sin_theta / theta, mask).float()
directions_stack[..., 2][mask] = -torch.masked_select(torch.cos(theta), mask).float()
if CameraType.EQUIRECTANGULAR.value in cam_types:
mask = (self.camera_type[true_indices] == CameraType.EQUIRECTANGULAR.value).squeeze(-1) # (num_rays)
mask = torch.stack([mask, mask, mask], dim=0)
# For equirect, fx = fy = height = width/2
# Then coord[..., 0] goes from -1 to 1 and coord[..., 1] goes from -1/2 to 1/2
theta = -torch.pi * coord_stack[..., 0] # minus sign for right-handed
phi = torch.pi * (0.5 - coord_stack[..., 1])
# use spherical in local camera coordinates (+y up, x=0 and z<0 is theta=0)
directions_stack[..., 0][mask] = torch.masked_select(-torch.sin(theta) * torch.sin(phi), mask).float()
directions_stack[..., 1][mask] = torch.masked_select(torch.cos(phi), mask).float()
directions_stack[..., 2][mask] = torch.masked_select(-torch.cos(theta) * torch.sin(phi), mask).float()
for value in cam_types:
if value not in [CameraType.PERSPECTIVE.value, CameraType.FISHEYE.value, CameraType.EQUIRECTANGULAR.value]:
raise ValueError(f"Camera type {value} not supported.")

Which makes sense to me. The current fix also seems fine though!

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's actually the way I originally wrote the fix, but decided to fix the loop instead since it seemed more in line with the intentions of the original author.

I don't have a strong opinion on which way is better, but I don't have a way to test anything other than fisheye and perspective cases so I figured the smaller change was safer.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

makes sense, thanks @decrispell!

@jb-ye jb-ye merged commit e2a0915 into nerfstudio-project:main Sep 10, 2024
2 of 3 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants