Incorrect orientation for displayed SEG overlay

[fedorov]

Bug Report

Describe the Bug

We have an inconsistency in displaying segmentation for T1 for this study (and for all segmentations in LGG/GBM collections) between Slicer and OHIF.

What steps can we follow to reproduce the bug?

It appears that all of the segmentations from the TCGA-GBM and TCGA-LGG collections are affected. A URL to the specific study is available in this slack thread. All of the segmentations in that cohort were created by dcmqi being converted from NIfTI, and were round-trip verified.

Notably, orientation of the SEG is different than MR for all those cases. It was observed that overlay is wrong in MPR as well.

Quoting @pieper:

I'm thinking now that it would make sense for the vtk view to be wrong if it got the image orientation vectors from cornerstone rather than getting them directly from dicom.

[pieper]

The data works with this code: https://github.com/dcmjs-org/dcmjs/blob/master/examples/vtkDisplay/index.html#L405-L447

[VusionTechCo]

Does the NIFTI file have a correct coordination? If you converted DICOM to NIFTI using dcm2nii.exe tool, usually it messed up the coordinates.

Thanks for the suggestion, but in this case all the data (background and segmentation) is in dicom.

[fedorov]

I updated the title of the issue, since it's been confirmed to be an OHIF issue.

[fedorov]

Here's the URL for a study that contains the data illustrating the issue: https://idc-sandbox-000.firebaseapp.com/projects/idc-dev-etl/locations/us-central1/datasets/idc_tcia_dev/dicomStores/idc_tcia/study/1.3.6.1.4.1.14519.5.2.1.3344.2526.782575807786219948893598067532

SEG is listed on the left, but when selecting segmentation on the right panel, it says there are 0 segments, which is not the case - I downloaded the study and confirmed that it does include segments.

[fedorov]

Correction - this is the study in question: https://idc-sandbox-000.firebaseapp.com/projects/idc-dev-etl/locations/us-central1/datasets/idc-tcia/dicomStores/idc-tcia/study/1.3.6.1.4.1.14519.5.2.1.4591.4003.241850919885310339695393380617

The one referenced above is for the 1p19q_deletion collection, which in fact was rendering correctly in OHIF at the time I was testing it before submitting to TCIA, so it might be a different issue in OHIF.

[fedorov]

As mentioned in ImagingDataCommons#8 (comment), this is not resolved.