Remove `Session.array_transform` attribute (obsolete single-transducer-pose model)
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 3/5
- Tiempo estimado
- 1-2 días
- Aptitud para principiantes
- 72/100
Línea de trabajo
Comienza con src/openlifu/db/session.py e inspecciona la serialización de Session. Después, revisa la construcción de Session en examples/tutorials/02_Database_Interaction.py y en su notebook correspondiente. Ejecuta las pruebas de base de datos en tests/test_database.py e inspecciona tests/resources/example_db/ en busca de datos legacy de array_transform. Se considera terminado cuando los fixtures y ejemplos actuales ya no hagan referencia al campo, mientras from_dict siga cargando sesiones legacy.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
Summary
Remove the array_transform: ArrayTransform field from openlifu.db.Session, along with its to_dict / from_dict handling, the associated docstring notes, and every reference in examples, tests, and test-resource JSON.
Motivation
Session.array_transform was designed around the assumption that a session has a single canonical "the transducer position." In SlicerOpenLIFU that assumption no longer holds:
- Each page that renders the transducer (pre-planning, localization, solution) picks whichever of the persisted transforms it needs (a specific approved virtual-fit result, a specific approved transducer-tracking result, or -- on the localization page -- both simultaneously).
- The full list of transducer transforms lives in
session.virtual_fit_resultsandsession.transducer_tracking_results, keyed by target / photoscan. - Approval invalidation is now driven per-VF and per-TT rather than by writing back a single pose.
As a result, SlicerOpenLIFU has stopped reading and writing session.array_transform (see the accompanying downstream PR). The field is now unused by the primary consumer and only serves to confuse the persistence model.
Scope of changes required in this repo
src/openlifu/db/session.py- Remove the
array_transformfield definition onSession. - Remove the corresponding
to_dict/from_dicthandling forarray_transform. - Update the
solution_idfield docstring, which currently claims the id is "cleared whenever the array_transform changes." That invalidation policy needs to be reconsidered (probably driven by VF / TT approval changes on the consumer side); at minimum, drop the array_transform reference from the doc.
- Remove the
examples/tutorials/02_Database_Interaction.pyand the matching.ipynb-- drop thearray_transform=ArrayTransform(...)argument from theSession(...)construction.tests/test_database.py-- remove assertions onsession.array_transform.matrix.shape/.unitsand any loop variables namedarray_transformthat come from the same fixture.- Test resource JSON files under
tests/resources/example_db/that carry an"array_transform"block -- either drop the block or regenerate the fixtures so they no longer contain it.from_dictshould tolerate the field being absent, so old on-disk sessions still load cleanly. - Sample database (
openlifu-sample-databaserepo) sessions currently carry an"array_transform"block too; that repo will need a matching sweep, but that is out of scope for this issue.
Backwards compatibility
Session.from_dict should silently ignore a legacy "array_transform" key so that existing on-disk sessions (including the pinned openlifu-sample-database fixtures) still load with the new library version.
Downstream
Coordinated with the SlicerOpenLIFU cleanup that decommissions the array_transform read/write path on the consumer side.
- Lenguaje dominante
- Python
- Estrellas
- 29
- Forks
- 20
- Merge medio
- 19 h 51 min
- PR fusionados (30 d)
- 5
Preparar el entorno
- Sin Dockerfile ni archivo de Docker Compose
- Sin plantilla de pull request
- Leer la guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de OpenwaterHealth/openlifu-python
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
-
Save Focal Gain LUT into a data file (json, csv, etc.) to make the source code file shorter.Posiblemente ocupada @HussainAther la tomó hace 81 días. Abiertoenhancement
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
OpenwaterHealth/openlifu-python#448 · 2 comentarios ·
-
Dificultad 5/5 Más de una semana Aptitud para principiantes 25/100
-
Reconstruction quality is inconsistent +poor across runs on identical input + very slow processingQuizá libre de nuevo @stahir715 la tomó hace 59 días y no hay ningún pull request abierto. Abierto
OpenwaterHealth/openlifu-python#496 · 7 comentarios · 2 asignados ·
Todos los issues de OpenwaterHealth/openlifu-python
Issues similares
-
Add `django-upgrade` to the CIAbiertodependencies feature github_actions good first issue
Dificultad 2/5 1-3 horas Aptitud para principiantes 62/100
wemake-services/wemake-django-template#3149 ·
Los mantenedores suelen responder en 1 día
-
[request] vsg/1.1.16Abiertoupstream update
Dificultad 2/5 1-3 horas Aptitud para principiantes 65/100
conan-io/conan-center-index#31142 ·
Los mantenedores suelen responder en 1 día
-
area:core bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
Los mantenedores suelen responder en 1 día
-
request-theme
Dificultad 2/5 Menos de una hora Aptitud para principiantes 70/100
LizardByte/ThemerrDB#8877 · 1 comentario ·
Los mantenedores suelen responder en 1 día
-
area/install-update comp/gateway P0 sweeper:risk-compatibility type/bug
Dificultad 2/5 Menos de una hora Aptitud para principiantes 72/100
NousResearch/hermes-agent#135997 · 3 comentarios ·
Los mantenedores suelen responder en 1 día