Viewers: Failure to load segmentation

Yes, we don’t need to rush with this. Let’s wait to hear from Igor first.

I am fine with any way that is most expedient, we don’t need to dwell on this, but I find this approach to be misleading. I do not like this inconsistency in flagging problematic series in UI, but I also don’t know the implementation to appreciate the challenges in implementing more uniform user experience, so it’s your call in the end.

Okay, yes, I recall now that the vtk MPR code is getting the volume data from the 2D cornerstone code - this has cropped up before. Thanks for the reminder @Punzo 👍

Since OHIF is moving toward unifying 2D and 3D approaches I would not want to invest a lot of work in handling this case for the current viewer code and instead just detect it and say it’s not supported for now. Better to invest our effort into developing and adopting a more unified solution. This is something we should discuss in the context of briefing everyone on the state of other developments going on in the OHIF community to avoid divergent work.

Thank you Davide. Let me investigate, and let’s hold https://github.com/dcmjs-org/dcmjs/pull/198 for now.

Hi @fedorov I checked the data.

the segmentation with 4 segments gets loaded with no problem (second segmentation in the seg UI combobox). P.S.: I had to force the loading (by click and drop of the series icon from the left column into the viewport) since the first segmentation does not load and gives errors.

The segmentation with only 1 segment I would say that it is not completely clean, if you navigate the DICOM in the Tag Browser you can see that:

1. PerFrameFunctionalGroupsSequence is an array of 116 elements instead of 21 (the data have 21 frames and the segmentation has only 1 segment).
2. Of the 116 elements only 21 have the SourceImageSequence information (which we use to load the segmentation in the array buffer).
3. So if I ignore the 95 elements with missing informations (which I guess they should simply not exist, see fix in dcmjs https://github.com/dcmjs-org/dcmjs/pull/198), the segmentation still loads wrongly because the Columns and Rows dicom attribute are wrong (320x320 instead of 384x384).

I am not sure how Slicer loads the segmentation since looks like the DICOM attributes have conflicts.

Should we implement further checks in dcmjs? e.g. comparing the Columns and Rows attributes between segmentation and the source image?

See image: