Does `world_frame_offset` still need applying?

The release manifest records a 23 cm world-frame offset for the five 2026-05-19 episodes, and no code reads it. This applies it and measures what changes.

The field

data/motherboard/episodes.jsonl

  date          world_frame_offset (m)      episodes
  2026-05-10    [0.0,  0.0, 0.0  ]              12
  2026-05-11    [0.0,  0.0, 0.0  ]              15
  2026-05-19    [0.23, 0.0, 0.175]               5

Built both ways: build_view_actions.py as-is, and with --apply-world-offset, which adds the vector to the translation before the projection. Rotation is untouched, and the tactile action is identical either way — dp = R_t^T(p_t+1 − p_t) cancels any constant translation, so only the camera-view half of the action can change.

What changes

episode	offset	shift (px)	max	in-frame as-is	in-frame w/ offset
0519_episode_000	[0.23, 0.0, 0.175]	219	276	100.0%	78.7%
0519_episode_001	[0.23, 0.0, 0.175]	221	280	100.0%	83.2%
0519_episode_002	[0.23, 0.0, 0.175]	219	268	100.0%	85.9%
0519_episode_003	[0.23, 0.0, 0.175]	220	246	100.0%	73.3%
0519_episode_004	[0.23, 0.0, 0.175]	220	258	100.0%	71.0%
the other 27 episodes have a zero offset and are bit-identical either way (shift 0.0000 px) — a built-in control

Applying it moves the projected gel centre 220 px on a 640-wide frame — a third of the image — and pushes 22% of the points out of frame entirely.

Which one is right

No labels needed: AllTracker already says where the image is moving, and a correct projection must put the sensor where the motion is. Score = fraction of moving frames whose projected cell falls in that frame's top-10% flow cells. Chance is 0.10.

episodes	as-is	offset applied
2026-05-19 (offset ≠ 0)	0.74	0.36
2026-05-10 / 05-11 (offset = 0, control)	0.61	unchanged

The control is the important row: those dates carry a zero offset, so their as-is score is what a correct projection looks like on this rig. 05-19 as-is sits in the same band; 05-19 with the offset applied does not.

projection overlay — All five 05-19 episodes at three time points, plus a 05-10 control on the bottom row. **○ green** = as-is, **□ red** = offset applied, arrow = the shift. On the control row the two coincide exactly, because that date's offset is zero.

Verdict

The offset is already applied in this copy of the data. Adding it again moves the projection off the sensor and onto bare table, on five episodes that are all in the training split. The manifest field is provenance of a correction made upstream, not a pending one.

The likely reason the two readings disagree: the parquets here are not the original release. data/motherboard/meta/*.parquet was produced by twm.force_recovery.export_force_columns from /media/yxma/Disk1/twm/release/... (not mounted here), and the manifest that travels with it uses a flat world_frame_offset key rather than the original's nested calib_epoch.world_offset_m. Different file, same numbers — one before the correction, one after.

Two further checks pointing the same way, both independent of the camera calibration:

Sensor position. Mean sensor_left_pose x is 0.33 m on 05-19 vs 0.29 m on 05-10 — the same workspace. A pending 0.23 m offset would put them 0.23 m apart.
Object position. The motherboard sits at a fixed station; mean object_pose differs between the dates by [0.034, 0.004, 0.039] m, not by [0.23, 0, 0.175].

Settling it definitively

If the original release can be mounted, one diff decides it:

f = lambda p: np.asarray(pq.read_table(p, columns=["sensor_left_pose"])
                           .column(0).to_pylist())[:, :3]
a = f("/media/yxma/Disk1/twm/release/motherboard/meta/2026-05-19/episode_000.parquet")
b = f("data/motherboard/meta/2026-05-19/episode_000.parquet")
print((b - a).mean(0))     # [0.23 0. 0.175] -> the export applied it