Segmentation on series that has several ImageOrientationPatient

[sinanmb]

Hi,

I'm working on a series that has several instances/slices with varying orientations. When I paint a segmentation on several instances that do not share an orientation, only the first orientation is used.

How can we save a segmentation on several instances with varying orientations?

Thanks

[razorx89]

Unfortunately, this is currently not possible. The MultiClassWriter only supports serializing a single sitk.Image, which is a voxel cube with only one origin and one orientation matrix. How would you load the image series, or more importantly your segmentations, with SimpleITK? I will track this as a potential enhancement.

However, I don't know of any other tool that currently supports this.
@fedorov Do dcmqi and/or OHIF support this?

[fedorov]

No, this wouldn't work with dcmqi either. What kind of an image is that? How does it load in SimpleITK?

[sinanmb]

It's an MR Lumbar study acquired axially. However, every 5 slices or so, the orientation changes to be parallel to that of the intervertebral disc. It's still the same series, but with multiple slabs at different orientations. In ITK snap, the full set of DICOM loads as the matrix size is the same across theseries, but there's probably an error for the rest of the slabs, as the slice orientation changes as we scroll. We can see that in the sagital view of an axial acquisition, where the anatomy is not continuous.

Quick question, in the dicom seg file, there's a dicomtag "SharedFunctionalGroupsSequence (5200,9229), an associated subgroup PlaneOrientationSequence (0020,9116) which contains the ImageOrientationPatient (0200,0037) tag. It seems that there can be multiple items there. Would it be possible to use this to list orientations for all slabs?

[razorx89]

It would be possible to define the PlaneOrientationSequence>ImageOrientationPatient in PerFrameFunctionalGroupsSequence. The problem is I don't know how I should detect this orientation change and match slices to DICOM files if you are passing an ITK image which only has a single orientation associated. And this would have to be supported for the reading as well. This is not impossible for DICOM-SEG, I currently just don't know how the API could look like for this use case.

[fedorov]

This is a rather unusual case, and the first steps should be 1) confirm the image series you have is valid according to the standard; 2) identify if there is any viewer that can load it correctly (did you check 3D Slicer?); 3) check how it is handled by ITK. Until those are resolved, I would say it is premature to work on adding support of SEG conversion tools for this type of data.

[sinanmb]

Slicer3D splits the series in multiple slabs and we can individually load them, while ITK snaps loads all slices, and does not consider the different orientations. So the Dicom reading capabilities of Slicer3D can handle this apparently.

[fedorov]

So this is not a multiframe instance? You have one file per slice, right?

If that is the case, the most expedient approach would be to split your DICOM instances into separate folders by ImageOrientationPatient, and when you run the conversion into DICOM SEG, convert the segmentations corresponding to the individual orientations separately.

[benodry]

Right, thanks @fedorov. It's not multiframe. We're trying to do this approach but in the OHIF framework. So we have to incorporate the split in the dicom reader and handle the "slab" selection for a smooth workflow to display back the dicomseg. It seems that even when having multiple dicom seg files (one per slab), linking them to the full series only partially displays the segmentation (the one matching the orientation from the first slab). We were just curious to see whether incorporating this info in 1 dicom-seg could make sense. Most of the MR MSK spine exams (Lumbar or Cervical) have multiple orientations as they have to follow the curvature of the spine to be parallel to the Intervertebral disc.

[fedorov]

linking them to the full series only partially displays the segmentation (the one matching the orientation from the first slab)

I am not sure I understand. If you have one segmentation object per slab, then you would load only the slices that correspond to that segmentation from the slab. I think putting all segments for varying orientations into a single segmentation object will be problematic in practice.

[benodry]

Sorry for the delay. Yes, we'll try creating slab based on orientations in OHIF, like it's done in Slicer3D. From there on, it should be easier to handle multiple segmentation files. crossing fingers. Thanks for the help!