rays reshape fix#958
Conversation
0f951af to
b5c8aee
Compare
b5c8aee to
9196497
Compare
|
@rodlima78, @vince-brisebois, could you plz review? |
There was a problem hiding this comment.
gsplat/rendering.py:1586 (outside this PR's diff)
The same rays shape mismatch exists in the autograd-path _rasterization() function: line 1398 asserts rays.shape == batch_dims + (C, H, W, 6), but rays is then passed unmodified to rasterize_to_pixels_eval3d at lines 1586 and 1631. rasterize_to_pixels_eval3d (in gsplat/cuda/_wrapper.py) just forwards to rasterize_to_pixels_eval3d_extra, which assert_shapes (batch_dims + (C, P, 6)) — so this path will fail the same assertion that PR 958 was created to fix. Consider mirroring the reshape (rays = rays.reshape(rays.shape[:-3] + (rays.shape[-3] * rays.shape[-2], 6))) before the rasterize call in _rasterization() as well, otherwise eval3d rendering through the autograd path remains broken.
Generated by a review agent (code review)
The eval3d pixel rasterizer (rasterize_to_pixels_eval3d_extra) expects per-ray input flattened as (..., C, H*W, 6): it derives P = rays.shape[-2] and its assert_shape wants rank (num_batch_dims + 3). The public API above takes (and asserts) the image-shaped (..., C, H, W, 6), so flatten the H, W dims here. Row-major flattening matches the kernel's pixel index (row * W + col) and the image-shaped output, so no reshape is needed on the returned colors/alphas.
#967