Skip to content

Refactoring: io, project, volume/annotation

There are some bad design choices in the organization of the code which should be addressed fairly soon. The utils module is messy -- as always -- and the volumeio module mixes I/O with controller operations with the execute_numpy_filter etc. Projects and Annotations are too central to be stuck in utils, and we should make a more complete separation between "Volumes" and "Annotations" in the JSON files and in the code. Having a semi-inheritance Element -> Volume, Annotation doesn't really work when Volume is volumeio.volume and Annotations is utils.annotations. It's weird.

JSON Projects

We should move to something like:

{
   <project metadata>,
   "volumes": { <uid>: <volume>, <uid>: <volume>... },
   "annotations": { <uid>: <annotation>, <uid>: <annotation>...}
}

Code refactoring

General structure:

  • io
    • volume.py
    • annotation.py
    • project.py
  • model
    • volume.py
    • annotation.py
    • project.py
  • registration
  • segmentation
  • transform
  • utils
    • logger.py
    • vectors.py
  • loaders
    • loaders.py
    • bruker_volume.py
    • dicom_volume.py

Such that the model classes are dataclasses.dataclass which directly mirror the information in the JSON. So for Volumes, we have in the model something like:

@dataclass
class VolumeModel:
    uuid: str
    type: str
    name: str
    local: bool
    path: str
    annotations: list[str]

    def load(self) -> Volume:
        ...

And the I/O is the same as before, with VolumeModel.load using the registered loaders to return a io.volume.Volume object.