[jacoblambert]

Summary

Implements the decision in #311: in 1.0, only key frames belong to a sample, so non-key frames have sample_data.sample_token: null. Code that needs the samples around a non-key frame walks its channel to the key frames, explicitly.

In 0.x, non-key frames (about 90% of sample_data in our datasets) point to the next sample, as in nuScenes. That link is easy to misread: it is not the frame's own sample, and not the nearest one.

Changes

• 0.x conversion: non-key frames get sample_token: null (V0Converter.convert_sample_data).
• New T4Devkit methods, for whoever relied on the 0.x link:
  • get_prev_key_frame(sample_data_token): the key frame at or before the frame, walking prev.
  • get_next_key_frame(sample_data_token): the key frame at or after it, walking next.
  • get_nearest_key_frame(sample_data_token): the closer of the two in time (the earlier on a tie).
  • Each returns a sample_data token, or None; sample_data.sample_token of that frame gives the sample.
• get_box3ds on a non-key frame: same result as before. It interpolated between the sample the 0.x link pointed to and its previous sample; it now finds that sample through get_next_key_frame. After the last key frame (no next one), it returns the previous key frame's boxes. None of the local datasets has frames after the last key frame.
• get_box2ds on a non-key frame: returns the 2D labels of that frame. Before, it returned the labels of the next sample, which are on other images.
• sample.ann_2ds holds the labels of key frames only, since non-key frames no longer link to a sample.
• Docs: docs/schema/v1/index.md (loading 0.x).

Tests

tests/test_tier4.py::test_non_key_frame: one LiDAR frame of the 0.x sample made non-key (with the 0.x link to the next sample). It loads with sample_token: None; the previous / next / nearest key frames are found; get_box3ds gives the boxes of the next sample. Fails without the change.

[jacoblambert]

Memo: This approach was deemed inappropriate, instead include sample even for key frames.