Viewers: [IDC Discussion] Should the RTSTRUCT show contours in the side panel if no contours are stored?

[JamesAPetts]

In #1896 I fixed the immediate issue presented by #1892, however we need to decide the best user experience for this case:

• The ROIContourSequence contains metadata about a specific ROINumber.
• No contours for that ROINumber are present in the StructureSetSequence.

At the moment I decided to show the metadata to the user, and warn with a notification when that the contours don't exist when the user tries to jump.

However we could choose to hide the ROI Contours that have no related structures from the list entirely, so that only contours with actual StructureSet data are shown.

I personally think keeping the contour metadata in the list is better, as it indicates that the data may be broken/exported incorrectly from source, perhaps we should grey out the contours to indicate they have no data? What's your opinion @fedorov @pieper ?

[fedorov]

Yes, I think the approach you suggested is reasonable. Maybe those contours can be shown with "exclamation"/warning sign icon in the list, since we know while forming the list that they will not render?

[JamesAPetts]

• Grey out the contours.
• Add a tooltip which shows the current notification error.

[JamesAPetts]

@fedorov Could you find out/check if the study referenced in #1892 is now rehosted on the IDC dev server?

[fedorov]

I am able to reproduce it with this in sandbox https://idc-sandbox-000.firebaseapp.com/projects/idc-dev-etl/locations/us/datasets/pre-mvp-temp/dicomStores/cross-collection-temp/study/1.3.6.1.4.1.14519.5.2.1.1706.4009.279236404491517275639164431409.

Also reproducible with viewer-latest, just put the study UID in the URL.

Specifically, it fails with the "CTV57 (ORGAN)" structure.

[fedorov]

@JamesAPetts so I looked at the RTSTRUCT for the study above, and specifically at the contours that trigger this error:

It appears that those first 3 contours that fail to render are not missing, but that ContourGeometricType is set to POINT instead of CLOSED_PLANAR (specifically, see ROINumber 1):

  (fffe,e000) na (Item with undefined length #=3)         # u/l, 1 Item
    (3006,002a) IS [255\0\0]                                #   8, 3 ROIDisplayColor
    (3006,0040) SQ (Sequence with undefined length #=1)     # u/l, 1 ContourSequence
      (fffe,e000) na (Item with undefined length #=4)         # u/l, 1 Item
        (3006,0016) SQ (Sequence with undefined length #=1)     # u/l, 1 ContourImageSequence
          (fffe,e000) na (Item with undefined length #=2)         # u/l, 1 Item
            (0008,1150) UI =CTImageStorage                          #  26, 1 ReferencedSOPClassUID
            (0008,1155) UI [1.3.6.1.4.1.14519.5.2.1.1706.4009.225553464433262834490995414397] #  64, 1 ReferencedSOPInstanceUID
          (fffe,e00d) na (ItemDelimitationItem)                   #   0, 0 ItemDelimitationItem
        (fffe,e0dd) na (SequenceDelimitationItem)               #   0, 0 SequenceDelimitationItem
        (3006,0042) CS [POINT]                                  #   6, 1 ContourGeometricType
        (3006,0046) IS [1]                                      #   2, 1 NumberOfContourPoints
        (3006,0050) DS [13.4131\37.4609\-1010.5]                #  24, 3 ContourData
      (fffe,e00d) na (ItemDelimitationItem)                   #   0, 0 ItemDelimitationItem
    (fffe,e0dd) na (SequenceDelimitationItem)               #   0, 0 SequenceDelimitationItem
    (3006,0084) IS [1]                                      #   2, 1 ReferencedROINumber
  (fffe,e00d) na (ItemDelimitationItem)                   #   0, 0 ItemDelimitationItem

So either it is a missing feature/bug that POINT contours are not displayed, or at the very least the error message should be changed to something like "POINT contour type is currently not supported".

[JamesAPetts]

Good catch, we could render points rather easily actually, perhaps we should just do that?

[fedorov]

Easily = Yes!

[JamesAPetts]

I'll make a new issue for point rendering.