Skip to content

viz: one keypoint renderer, the horizon trace - #669

Draft
RyanPCo wants to merge 1 commit into
ryanco/flagship-kp-configsfrom
ryanco/keypoint-renderer
Draft

RyanPCo wants to merge 1 commit into
ryanco/flagship-kp-configsfrom
ryanco/keypoint-renderer

Conversation

@RyanPCo

@RyanPCo RyanPCo commented Sep 19, 2026 •

Copy link
Copy Markdown
Contributor

_viz_keypoints flattened a (T, D) chunk to (T * 21, 3) and then drew slots
0..20 only -- for k in range(21) for the dots, and edge_ranges over the same
21 -- so an action chunk collapsed to its first timestep and the overlay never
moved, however long the horizon. Every projected point past frame 0 was
computed and thrown away. That is what a whole training campaign's validation
videos turned out to be (2026-09-18).

This replaces it with _viz_keypoints_horizon_trace, which draws the chunk as a
trajectory and degenerates to per-slot start markers for a lone timestep (it
promotes (D,) to (1, D) itself). The old renderer is deleted rather than left
reachable: Human.viz(mode="keypoints") has one path, and a renderer you can
reach by accident is one you will reach.

Consequences, all intended: the dataset inspector, the Aria tutorial and
mecka_keypoints_viz render through the trace now, so the single-frame callers
show per-slot start markers instead of a posed skeleton, and Aria's raw
21-keypoint edge tables go with the renderer that consumed them -- they had no
other caller.

tests/unit/test_chunk_renderer.py pins both halves: that the trace follows the
chunk, and that no second renderer is reachable from Human.

🤖 Generated with Claude Code

https://claude.ai/code/session_01HjCQBqQCr2igFEMR7yUovw

RyanPCo commented Sep 19, 2026 •

Copy link
Copy Markdown
Contributor Author

Warning

This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
Learn more

This stack of pull requests is managed by Graphite. Learn more about stacking.

@RyanPCo
RyanPCo force-pushed the ryanco/keypoint-renderer branch from e93fc54 to d470b0b Compare September 20, 2026 19:09
@RyanPCo
RyanPCo force-pushed the ryanco/flagship-kp-configs branch from 1afe113 to ce16716 Compare September 20, 2026 19:09
@RyanPCo
RyanPCo force-pushed the ryanco/keypoint-renderer branch from d470b0b to 75f90fe Compare September 21, 2026 18:45
@RyanPCo
RyanPCo force-pushed the ryanco/flagship-kp-configs branch from 402c544 to e52d66c Compare September 22, 2026 13:18
@RyanPCo
RyanPCo force-pushed the ryanco/keypoint-renderer branch from 75f90fe to 07d7a99 Compare September 22, 2026 13:18
@RyanPCo
RyanPCo force-pushed the ryanco/flagship-kp-configs branch from c3ae357 to c5f561f Compare October 12, 2026 21:50
@RyanPCo
RyanPCo force-pushed the ryanco/keypoint-renderer branch from 9339bac to cfeee2a Compare October 12, 2026 21:50
@RyanPCo
RyanPCo force-pushed the ryanco/keypoint-renderer branch from cfeee2a to e3becc1 Compare October 12, 2026 23:19
@RyanPCo
RyanPCo force-pushed the ryanco/flagship-kp-configs branch from c5f561f to c09f941 Compare October 12, 2026 23:19
@RyanPCo RyanPCo mentioned this pull request Oct 19, 2026
@RyanPCo
RyanPCo force-pushed the ryanco/flagship-kp-configs branch from c09f941 to e9f4073 Compare October 19, 2026 19:45
@RyanPCo
RyanPCo force-pushed the ryanco/keypoint-renderer branch 2 times, most recently from 1fb4886 to c27cd6d Compare October 19, 2026 20:22
@RyanPCo
RyanPCo force-pushed the ryanco/flagship-kp-configs branch from 0f56bf9 to 028cd76 Compare October 30, 2026 18:27
@RyanPCo
RyanPCo force-pushed the ryanco/keypoint-renderer branch from c27cd6d to 0a796ff Compare October 30, 2026 18:27

@RyanPCo RyanPCo left a comment

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Automated adversarial review (read-only; findings were checked by a second skeptical pass before posting): 1 low, 2 nit.

5. Render side-by-side: left half = Aria viz with Aria.FINGER_EDGES; right
half = fitted MANO viz with Human (=Mecka) FINGER_EDGES.
5. Render side-by-side: raw Aria keypoints on the left, the fitted MANO on
the right, both through Human.viz(mode="keypoints").

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

low (correctness): The left panel still feeds Aria's raw 21-slot layout (tips at 0-4, palm root at 5; that is what the deleted ARIA_FINGER_EDGES described) into Human.viz(mode="keypoints"). _viz_keypoints_horizon_trace hard-codes FINGERTIP_SLOTS=(4,8,12,16,20). The wrist comes out right because 138-D reads it from the wrist block, but the 'thumb' trace is now the Aria pinky tip and the other four are mid-finger joints, so the comparison panel is mislabelled. Either pass Aria's tip slots through the existing fingertip_indices kwarg (e.g. fingertip_indices=(0,1,2,3,4)), permute the batch to MANO order first, or drop the left panel. The docstring line should then say which of these it does.

Comment thread egomimic/utils/viz_utils.py Outdated
f"got {actions.shape}"
)

if actions.shape[-1] == 2 * (3 * _N_KP + 9):

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

nit (simplification): Widths are now listed twice: _KEYPOINT_WIDTHS (built from the pose sizes) and this elif chain, which writes 144/140/138 as 2 * (3 * _N_KP + n) and is harder to read than the literals it replaced. A single table such as _SPLIT_KWARGS = {144: dict(wrist_in_data=True, is_rot6d=True), 140: dict(wrist_in_data=True), 138: dict(wrist_in_data=True, is_quat=False), 126: dict(wrist_in_data=False)} could drive both the validation and the _split_keypoints(actions, **_SPLIT_KWARGS[D]) call.

Comment thread egomimic/rldb/embodiment/human.py Outdated
colors = cls.FINGER_COLORS
dot_color = cls.DOT_COLOR
return _viz_keypoints(
# The horizon trace is the ONLY keypoint renderer. A chunk draws

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

nit (comments): This comment narrates history ('rendered motionless keypoint overlays for a whole 50k-step campaign'). The dated anecdote in the tests/unit/test_chunk_renderer.py docstring does the same. Cut it to the constraint, e.g. 'Single keypoint renderer; a (D,) step draws as start markers', and put the story in the commit message. The np.asarray(viz_data) here is redundant because the callee already does it.

_viz_keypoints flattened a (T, D) chunk to (T * 21, 3) and then drew slots
0..20 only -- `for k in range(21)` for the dots, and edge_ranges over the same
21 -- so an action chunk collapsed to its first timestep and the overlay never
moved, however long the horizon. Every projected point past frame 0 was
computed and thrown away. That is what a whole training campaign's validation
videos turned out to be (2026-09-18).

This replaces it with _viz_keypoints_horizon_trace, which draws the chunk as a
trajectory and degenerates to per-slot start markers for a lone timestep (it
promotes (D,) to (1, D) itself). The old renderer is deleted rather than left
reachable: Human.viz(mode="keypoints") has one path, and a renderer you can
reach by accident is one you will reach.

Consequences, all intended: the dataset inspector, the Aria tutorial and
mecka_keypoints_viz render through the trace now, so the single-frame callers
show per-slot start markers instead of a posed skeleton, and Aria's raw
21-keypoint edge tables go with the renderer that consumed them -- they had no
other caller.

tests/unit/test_chunk_renderer.py pins both halves: that the trace follows the
chunk, and that no second renderer is reachable from Human.

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
Claude-Session: https://claude.ai/code/session_01THTuWdgk6M6pZ5Ya7ihZEF
@RyanPCo
RyanPCo force-pushed the ryanco/flagship-kp-configs branch from 028cd76 to 1c42a93 Compare October 30, 2026 23:05
@RyanPCo
RyanPCo force-pushed the ryanco/keypoint-renderer branch from 0a796ff to 17231a2 Compare October 30, 2026 23:05
@RyanPCo

RyanPCo commented Oct 30, 2026

Copy link
Copy Markdown
Contributor Author

Review findings: status after the fixup pass. The fixes are squashed into this PR's commits, and the whole stack was force-pushed.

Fixed

  • Tutorial now renders raw-Aria keypoints through MANO slot indices: The Aria panel passes fingertip_indices=(0,1,2,3,4). The docstring and the panel titles now describe the tip slots rather than edges, since no edges are drawn.
  • Width dispatch duplicated between _KEYPOINT_WIDTHS and an if/elif chain: A single _SPLIT_KWARGS table, keyed by width, now drives both the validation and the _split_keypoints call.
  • Comment narrates campaign history instead of a constraint: Cut the comment to one line and removed the anecdote from the test_chunk_renderer docstring. Dropped the redundant np.asarray.

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.

1 participant