Add array_transform to SolutionInfo to preserve compute-time transducer pose
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 2/5
- Tempo stimato
- 1-3 ore
- Idoneità per principianti
- 75/100
Direzione di ricerca
Inizia da openlifu.db.session.SolutionInfo e analizza il modo in cui Session.from_dict decodifica le voci di solutions. Aggiorna tests/test_database.py per il campo opzionale array_transform, inclusi la decodifica di dict e il comportamento legacy di None; il lavoro è completato quando il valore sopravvive ai round trip del database.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
Add an optional array_transform: ArrayTransform | None field to
openlifu.db.session.SolutionInfo capturing the transducer array-to-volume
transform matrix that was used when the corresponding Solution was
computed.
Motivation
Downstream (SlicerOpenLIFU) currently renders a solution's PNP / intensity
volumes by parenting them under the transducer's transform node, then snapping
the transducer to whichever virtual-fit or transducer-tracking result is
currently approved. This means:
- If the currently-approved VF / TT changes between compute time and display
time, the PNP moves to the new pose rather than staying where it was
computed. - For a pre-solution (computed off a VF result), the VF approval may later
be revoked; there is then no way to display the solution at its original
pose because no transform survives.
The fix is to persist the exact matrix used at compute time on the
SolutionInfo provenance record. Consumers snap the transducer to that
matrix on display, so the PNP is invariant under later approval churn.
Details
- New field
SolutionInfo.array_transform: ArrayTransform | None(default
Nonefor legacy round-trips). __post_init__accepts a dict transparently soSession.from_dict
decodingsolutionsentries produces the correct type.- Round-trip tests added in
tests/test_database.py.
Downstream
Tracked in SlicerOpenLIFU#622: "Pre-Solution PNP overlay renders at wrong
position when navigating to Sonication Planner". That issue's fix consumes
this new field.
- Lingua principale
- Python
- Stelle
- 27
- Fork
- 21
- Merge medio
- 1g 20m
- PR unite (30g)
- 6
Guida per i contributori
Apri la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di OpenwaterHealth/openlifu-python
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
-
enhancement
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
OpenwaterHealth/openlifu-python#448 · 2 commenti ·
-
Difficoltà 5/5 Più di una settimana Idoneità per principianti 25/100
-
Reconstruction quality is inconsistent +poor across runs on identical input + very slow processing Aperta
OpenwaterHealth/openlifu-python#496 · 7 commenti · 2 assegnatari ·
-
Difficoltà 5/5 Più di una settimana Idoneità per principianti 35/100
OpenwaterHealth/openlifu-python#493 · 1 commento ·
Tutte le issue di OpenwaterHealth/openlifu-python
Issue simili
-
bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 75/100
stephrobert/dsoxlab#238 ·
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 75/100
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 75/100
sublimehq/package_control#1780 ·
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 65/100
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 70/100
nwg-piotr/nwg-displays#145 ·