ImagingDataCommons / slim

Interoperable web-based slide microscopy viewer and annotation tool
https://imagingdatacommons.github.io/slim/
Apache License 2.0
120 stars 38 forks source link

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

Closed hackermd closed 2 years ago

hackermd commented 2 years ago

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 commented 2 years ago

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 ...

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 commented 2 years ago

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 commented 2 years ago

@dclunie I implemented the logic you outlined:

Screen Shot 2022-06-30 at 4 34 47 PM

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

Punzo commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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

hackermd commented 2 years ago

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

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 commented 2 years ago

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

fedorov commented 2 years ago

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 commented 2 years ago

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

Thanks for your help!

hackermd commented 2 years ago

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.