Page MenuHomePhabricator

Bounding boxes / ROIs in MITK
Closed, ResolvedPublic

Description

Both in the contexts of segmentation and detection we have multiple feature requests within our division for a bounding box / ROI that goes beyond the Image Cropper bounding shape and is better integrated with the segmentation plugin.

The details of integration with the segmentation plugin are not yet finalized nor really discussed in depth. After a call with @m113r, I start already with a first draft of a JSON-based file format that suits all of our needs and is just flexible enough for future additions.

Requirements:

  • Axis-aligned bounding boxes
  • Multiple boxes per file
  • Optional reference to image (in particular useful when index coordinates are used)
  • Versioned to allow for future format-breaking changes
  • Extent specified as origin + size
  • Type of extent coordinates can be "Index", "ContIndex", or "World"
  • Boxes can have attributes like name, class, confidence, comment, or expected label value for segmentations and so on...
  • Support time-resolves images with adaptive boxes over time
Single box for a 3-d image
{
  "FileFormat": "MITK Axis-Aligned Bounding Boxes",
  "Version": 1,
  "Geometry": {
    "Type": "Path",
    "Path": "../images/foo.nii.gz"
  },
  "Properties": {
    "Comment": "Hello, world!"
  },
  "Frames": [
    {
      "ID": 0,
      "Type": "Box",
      "Extent": {
        "Type": "Index",
        "Origin": [ 10, 10, 10 ],
        "Size": [ 40, 20, 10 ]
      },
      "Properties": {
        "Name": "Tumor",
        "Class": "Malignant",
        "Confidence": 0.95,
        "Comment": "Please segment the tumor found at this location.",
        "LabelValue": 1
      }
    }
  ]
}
Single box partially changing over time for a 4-d image
{
  "FileFormat": "MITK Axis-Aligned Bounding Boxes",
  "Version": 1,
  "Geometry": {
    "Type": "Embedded",
    "Origin": [ 0, 0, 0 ],
    "Spacing": [ 1, 1, 3 ]
   },
  "Properties": {
    "Comment": "Hello, world!"
  },
  "Frames": [
    {
      "ID": 0,
      "Type": "Box",
      "Properties": {
        "Name": "Tumor",
        "Class": "Malignant",
        "Comment": "Please segment the tumor found at this location."
      }
    }
  ],
  "TimeSteps": [
    {
      "TimeStep": 0,
      "Frames": [
        {
          "ID": 0,
          "Extent": {
            "Type": "Index",
            "Origin": [ 10, 10, 10 ],
            "Size": [ 40, 20, 10 ]
          },
          "Properties": {
            "Confidence": 0.95,
          }
        }
      ]
    },
    {
      "TimeStep": 1,
      "Frames": [
        {
          "ID": 0,
          "Extent": {
            "Type": "Index",
            "Origin": [ 15, 15, 15 ],
            "Size": [ 40, 20, 10 ]
          },
          "Properties": {
            "Confidence": 0.92,
          }
        }
      ]
    }
  ]
}

The basic idea is to have a list of JSON objects for boxes and in case of a 4-d image, additional JSON objects for boxes for certain time steps. Static values of a box can be specified in the former JSON objects, dynamic values can be specified in the latter JSON objects for each time step. If both a static and dynamic value/attribute is specified, the dynamic value overrides the static default value/attribute. As the definition of a box can be split in this approach, each box must have an ID which is the same for a certain box in all time steps.

Revisions and Commits

rMITK MITK
Restricted Differential Revision
Restricted Differential Revision
Restricted Differential Revision
Restricted Differential Revision
Restricted Differential Revision
Restricted Differential Revision
Restricted Differential Revision
Restricted Differential Revision
Restricted Differential Revision
Restricted Differential Revision
Restricted Differential Revision
Restricted Differential Revision
Restricted Differential Revision
Restricted Differential Revision
Restricted Differential Revision
Restricted Differential Revision
Restricted Differential Revision
Restricted Differential Revision
Restricted Differential Revision
Restricted Differential Revision
Restricted Differential Revision
Restricted Differential Revision
Restricted Differential Revision
Restricted Differential Revision
Restricted Differential Revision
Restricted Differential Revision
Restricted Differential Revision
Restricted Differential Revision
Restricted Differential Revision
Restricted Differential Revision
Restricted Differential Revision
Restricted Differential Revision
Restricted Differential Revision
Restricted Differential Revision
Restricted Differential Revision
Restricted Differential Revision
Restricted Differential Revision
Restricted Differential Revision
Restricted Differential Revision
Restricted Differential Revision
Restricted Differential Revision
Restricted Differential Revision
Restricted Differential Revision
Restricted Differential Revision
Restricted Differential Revision
Restricted Differential Revision
Restricted Differential Revision
Restricted Differential Revision
Restricted Differential Revision
Restricted Differential Revision
Restricted Differential Revision
Restricted Differential Revision
Restricted Differential Revision
Restricted Differential Revision
Restricted Differential Revision
Restricted Differential Revision
Restricted Differential Revision
Restricted Differential Revision
Restricted Differential Revision
Restricted Differential Revision
Restricted Differential Revision
Restricted Differential Revision
Restricted Differential Revision
Restricted Differential Revision
Restricted Differential Revision
Restricted Differential Revision
Restricted Differential Revision
Restricted Differential Revision
Restricted Differential Revision
Restricted Differential Revision

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes

Thank you for the first draft. I had the following first thoughts:

  1. Is it realy helpfull needed to support index in the file. Why not just world coordinates and it is a thing for the serializing application to convert if needed. If we allow index, the geometry should be stored directly here to make it always interpretable information.
  2. There should be a posibility to store meta properties on top level (as we also do e.g. in the label set)
  3. For me RefImage is already one of those meta properties.
  4. How is RefImage defined? Just a file? Simple/easy to use but not very robust. We might keep that option, but I think it would be better to use support our PropertyReleations and e.g. use where possible DICOM Tags to encode references.
  5. We should allign the json format used to store properties here and in our segmentations... (therefore i.a. I would not introdice a new term (attributes) when there is a sementically equal term allready use in other places (properties)

Thanks for the feedback. 🙏

  1. Yes, all concrete requirements in that regard that we currently have from our stake holders are index coordinates and in case of @m113r in addition continuous index coordinates as that's the output type of the net. Hence, enforcing world coordinates is in my opinion an unnecessary burden for adoption. But, what I didn't mention so far is certain assumptions/rules that need to be fulfilled. In case of index coordinates the otherwise optional RefImage is mandatory or at least a strong warning must be issued in case of its absence. Otherwise you would be right and we would need to include geometry information which is a can of worms all of us want to avoid in the scope of this file format.
  2. Done.
  3. RefImage is essential in most cases (see 1) and as integral part I vote for having it separate from properties even though it is optional.
  4. That is up for discussion and hence I intentionally wasn't specific on the RefImage value. While we still need to talk about it I now made it a little bit more specific already by splitting it up into a Type (e. g. "Path" or "Task") and the actual Ref string. Maybe that's already enough flexibility for all future cases.
  5. Done.

@kislinsk thank you for the explanations. They do make sense.

On top of that I would propose to things for improving the current specification:

  1. Change "RefImage" to "RefGeometry"
"RefGeometry": {
  "Type": "Task",
  "Ref": "<Task Name>"
 },

Reason: in the end it is a ball about geometries and this would give us more freedom for having different types that represent the geometry.

  1. Introduce the type Geometry for RefGeometry

Reason: then you could directly encode in the format the reference geometry that should be used. I think that is a good compromise between offering data scientists, who have their pipeline and want just as easy as possible to create a valid file, a simple route by just reference an image that defines the geometry, while implementations that strive for robustness and have no problem with directly encode the geometry in the file (like I would recommend for our MITK implementation).

  1. Name Boxes mor generic. E.g. Frames or so

Reasion: That would allow to introduce later also other forms like spheres for indicating the bounds without having a semantic conflict in the terminology as they are no boxes.

  1. Done
  2. If the geometry is to be defined right in the file itself, I vote against a ReferenceGeometry type of "Geometry" but rather actually a "Geometry" JSON object. So it is either having a reference to something else that defines the geometry or specifying the geometry right in the file without any redirections.
  3. Done, also added "Type" to "Frames", which is "Box" for, well... boxes.

👍
I would propose to also standardizeand align some of the properties for the frames to be either in sync with MITK terminology or with DICOM.

currently draftedDICOMMITKMeaning
Name or class?SegmentLabelLabelHuman readable class name, i.a. used to denote the different classes in semantic segmentation; e.g. "metastasis" or "occlusions")
?TrackingIDTrackingIDhuman readable instance name, i.a. used to denote and differentiate instances in instant segmentation; e.g. "Metastasis 1"
?TrackingUIDTrackingUIDunique ID to identify instances in instant segmentation cross different images and points in time
LabelValueSegment NumberLabelValueunique value that identifies a certain instance in the data structure. Remark: do we really need that in detection as there is already the ID?
?Recommended Display CIELab ValueColorcolor that should be used for displaying the structure
?N/aLockedindicating the lock state of the structure in the application
?N/aVisibleindicating the visibility of the structure in the application
?N/aLockedindicating the lock state of the structure in the application
CommentSegment DescriptionDescription
kislinsk added a revision: Restricted Differential Revision.Nov 8 2023, 3:45 PM

Deleted branch from rMITK MITK: feature/T30155-ROI.

Deleted branch from rMITK MITK: bugfix/T30155-FixUnitTests.

kislinsk lowered the priority of this task from High to Normal.Nov 27 2023, 1:32 PM

Everything else will be handled in follow-up tasks as needed.