Improve handling of digital slides with images that have different frame of references

[hackermd]

Currently, Slim fails if images are passed to the Slide Viewer that have different values for Frame of Reference UID. This should be handled more gracefully. While all VOLUME and THUMBNAIL images shall have the same Frame of Reference UID, there may be situations where LABEL or OVERVIEW images may have a different Frame of Reference. Instead of raising an error we may just want to issue a warning and skip the LABEL or OVERVIEW images.

So far, we have assumed that all images that collectively constitute a digital slide have the same Frame of Reference UID. We need that in order to differentiate between images of the same physical glass slides that were acquired via different image acquisitions (i.e., re-scans). Moving forward a discussion will be needed regarding the definition of a digital slide (which is ill-defined in the DICOM standard - there is no Digital Slide IE) and any constraints that should apply.

cc @dclunie

[dclunie]

Partially replicated from "http://github.com/ImagingDataCommons/IDC-ProjectManagement/issues/1253" ...

With a view to future improvements that provide the user with a better experience and displays more valid data ...

AcquisitionUID was specifically added to deal with the need to describe a bunch of related stuff that was related to "a single continuous gathering of data" (including a scan of a slide) ... if it is present, I would suggest Slim take advantage of it.

Assuming the same ContainerIdentifier, and in the absence of AcquisitionUID, if there is/are within a single Series ...

• images of type VOLUME +/- THUMBNAIL, which share the same FrameOfReferenceUID (+/- the same PyramidUID) then it seems safe to assume they are one pyramid, though there could theoretically be more than one pyramid in the same Series (e.g., from two areas of tissue in the same scan); the common FrameOfReferenceUID is necessary to ascertain that layers of the pyramid are spatially related, and the presence of PyramidUID would be necessary to separate multiple pyramids in the same Series which could well share the same FrameOfReferenceUID and be offset by different locations.

• one image of type OVERVIEW and it has the same FrameOfReferenceUID as the previously selected pyramid, then it it seems safe to assume that OVERVIEW can be used to display the location of the pyramid (or pyramids, theoretically, if there were multiple and they could be separated).

• one image of type LABEL, it seems safe to assume that label can be displayed for that Series for the slide, regardless of its FrameOfReferenceUID, since there is no need to spatially correlate the LABEL and the other types of images.

If, on the other hand, there was more than one LABEL per Series (or more than one OVERVIEW, or retired LOCALIZER for that matter) then which to choose might be ambiguous, in the absence of AcquisitionUID, and it would be reasonable to suppress use of it.

I do not think that FrameOfReferenceUID is a good idea to use as a surrogate for AcquisitionUID, since two acquisitions may share the same FrameOfReferenceUID if the images have been registered and transformed to a common frame of reference, or one is a post-processed version of the other, or one is a set of segmentations or annotations of the other encoded as an image rather than an SR or SEG, etc., though hopefully these would not occur in the same Series ... It is a historical accident that FrameOfReferenceUID may have seemed a suitable surrogate but its definition and its location in the information model spans slides, images, and series.

That said, the primary reason for not using FrameOfReferenceUID as a surrogate for AcquisitionUID is the converse, to accept that some related images (LABEL vs. others) may have different values for FrameOfReferenceUID.

[hackermd]

Thanks for the detailed explanation @dclunie. I think this is a good approach.

Note, however, that while this approach works for OVERVIEW and LABEL images, it won't work in general for other image flavors. In the absence of Acquisition UID, we have no reliable way to group VOLUME images into digital slides other the Frame of Reference UID. I also tend argue that if images have been spatially registered and as a consequence have the same Frame of Reference UID, then they should be considered part of the same digital slide.

[hackermd]

@dclunie I implemented the logic you outlined:

It looks like the LABEL image has an incorrect Image Orientation (Slide).

[Punzo]

I think when we were designing the slides grouping, we decided to use the Frame of Reference UID, because the data were missing the Acquisition UID (at least the VOLUME type), at least with the first data that we had at the beginning.

[dclunie]

I agree about the incorrect ImageOrientationSlide for the LABEL - there is nothing in the SVS file to say what this should be, so I think in future I should just hardwire it differently so that those we have actually encountered rotate so that they are readable.

[hackermd]

Yeah, it's tricky. I have ran into this issue with my conversions, too. The orientation appears to depend on the software version.

[hackermd]

Based on @dclunie's recommendation, the logic of Slim for assigning SM image instances to digital slides is now as follows:

• VOLUME and THUMBNAIL images are grouped by ContainerIdentifier, FrameOfReferenceUID, and AcquistionUID (if available). This group of images constitutes a digital slide.
• LABEL and OVERVIEW images are filtered based on ContainerIdentifier, which must match the ContainerIdentifier of the VOLUME images
• If there is only one LABEL image, it is assigned to the digital slide. Otherwise, a LABEL image is only assigned if AcquisitionUID is available and if it matches the AcquisitionUID of the VOLUME images
• If there is only one OVERVIEW image, it is assigned to the digital slide. Otherwise an OVERVIEW image is only included if AcquisitionUID is available and if it matches the AcquisitionUID of the VOLUME images

If there are multiple LABEL or OVERVIEW images with the same AcquisitionUID (not sure whether this would ever occur in practice), Slim will select the first one for display (the instances are not sorted and the selection may change when the page is reloaded).

[dclunie]

@hackermd, thanks for taking care of this so quickly.

[fedorov]

Thank you Markus indeed. I hate to ask you about this, but now we need to update slim in that sandbox deploy that we have for our pre-v10 staging area.

[hackermd]

@hackermd, thanks for taking care of this so quickly.

Thanks for your help!

[hackermd]

Thank you Markus indeed. I hate to ask you about this, but now we need to update slim in that sandbox deploy that we have for our pre-v10 staging area.

Yes, I will draft a new release and update the dev app.