Current implementation
Points layer path metadata currently serves two purposes:
- Defining the viewer frame order used by point frame indices
- Defining which annotation rows participate in saving
After an annotation layer is remapped to a shared image frames stack e.g. because of extra frames with/from machine labels, its path list contains the full viewer path union.
However, the GT pr machine layer may "own" annotations for only a subset of those frames, as in a machine layer should own only its own keypoints, yet show them correctly within the path<->frame mapping
This can introduce unrelated all-NaN rows into the save DataFrame and incorrectly interfere with the deletion mechanisms in GT layers, and overall couples two distinct problems too tightly.
Proposed direction
Add a typed, serializable frame table to Points metadata.
Each image-related path should have an explicit role field/tag:
- Owned: belongs to the annotation layer and participates in saving that layer
- View only: present only for alignment with the shared viewer context
The frame table should be the authority for:
- Viewer path ordering
- Annotation ownership
- Save scope selection
Remapping should preserve existing ownership and mark newly introduced viewer paths as view only.
Point-to-DataFrame conversion should use all paths to resolve viewer frame indices. Save completion and deletion detection should use only owned paths.
The existing path list can temporarily remain as a generated compatibility projection.
Goals
- A machine layer with N owned frames remapped to a N+M frame viewer retains N owned and M view-only paths
- Saving that machine layer prepares only its N owned rows
- A GT layer remapped to additional view-only frames does not treat those frames as deletion candidates
- Deleting a keypoint on an "owned" GT layer frame always produces an explicit deletion and warning
- Frame ownership round trip through metadata serialization, remapping, and project path rewriting
- Path matching is performed once and reused for remapping and ownership transfers
- The frame table becomes the authoritative representation of ownership
Context
#228 prevents missing machine values from deleting existing GT annotations during machine-to-GT promotion.
This issue tracks the broader metadata refactor to ensure remapping changes a layer’s display context without expanding its annotation ownership or save scope.
Current implementation
Points layer path metadata currently serves two purposes:
After an annotation layer is remapped to a shared image frames stack e.g. because of extra frames with/from machine labels, its path list contains the full viewer path union.
However, the GT pr machine layer may "own" annotations for only a subset of those frames, as in a machine layer should own only its own keypoints, yet show them correctly within the path<->frame mapping
This can introduce unrelated all-NaN rows into the save DataFrame and incorrectly interfere with the deletion mechanisms in GT layers, and overall couples two distinct problems too tightly.
Proposed direction
Add a typed, serializable frame table to Points metadata.
Each image-related path should have an explicit role field/tag:
The frame table should be the authority for:
Remapping should preserve existing ownership and mark newly introduced viewer paths as view only.
Point-to-DataFrame conversion should use all paths to resolve viewer frame indices. Save completion and deletion detection should use only owned paths.
The existing path list can temporarily remain as a generated compatibility projection.
Goals
Context
#228 prevents missing machine values from deleting existing GT annotations during machine-to-GT promotion.
This issue tracks the broader metadata refactor to ensure remapping changes a layer’s display context without expanding its annotation ownership or save scope.