SVS: Incorrect pyramid levels with 6.8.0 #3757
Comments
|
This issue has been mentioned on Image.sc Forum. There might be relevant details there: |
|
Thanks to @petebankhead for the investigation on the source of this issue. https://forum.image.sc/t/problem-about-opening-some-svs-slides-in-qupath-v0-3-1-bio-formats-6-8-0/61404/15 seems to indicate this impacts a subset of SVS files. As the testing of #3733 suggests, we only have representative SVS sample files in the curated OME QA repository where An issue here is that reverting #3733 would solve this bug but cause a regression in other use cases. Solving this issue will require to improve the label/macro detection logic (https://github.com/ome/bioformats/pull/3733/files#diff-314c2ae6ccef06aa694ffa85cf5843ba9a42c62e312a561914894648d61ff09aR305) to handle the different scenarios. For complete reference, the Aperio specification document section related to label and macro images: A few initial thoughts:
Additionally, the label/macro detection logic could be controlled via a reader-specific option allowing the user to turn it on/off. |
|
Thanks @dgault and @sbesson The subfile type looks potentially useful, as does the (lack of) ImageDescription. Although I am faintly aware that some other software claims to write svs (e.g. 3DHistech's Slide Converter) and I don't know how closely it follows the Aperio specification document. In case QuPath could be useful for testing, I've just merged a PR that makes it easier to switch between Bio-Formats versions. The application can be launched from the source directory with or The latest code uses the trick of eliminating the 'impossible' resolutions, i.e. where the downsample value decreases at the next level. However this was still not enough to get things to work in 6.8.0: it seems that the levels that were requested were incorrect. In the meantime, I plan to make a QuPath release that reverts to 6.7.0 soon. |
|
Reopening this as there is still an ongoing issue in the thread which will require some further investigation: https://forum.image.sc/t/problem-about-opening-some-svs-slides-in-qupath-v0-3-1-bio-formats-6-8-0/61404/26 The file in question is located at https://dbarchive.biosciencedbc.jp/data/open-tggates-pathological-images/LATEST/images/2-nitrofluorene/Kidney/65141.svs |
|
Cross-linking to Pete's answer on the thread, the way OpenSlide makes the assignment between WSI and label/macro for the sample file mentioned in #3757 (comment) is based on the usage of tiles vs strips. This is in agreement with the relevant line of the specification - see #3757 (comment) and might be the next thing to try out in the reader |
|
This issue has been mentioned on Image.sc Forum. There might be relevant details there: https://forum.image.sc/t/fiji-wont-recognize-svs-files/63528/2 |
|
Possibly instance of this issue was reported in https://forum.image.sc/t/preview-error-when-tcga-svs-image-was-imported/67945 using a sample SVS file from the TCGA repository. Loooking at the TIFF structure With the current version of Bio-Formats, this is detected as a single multi-resolution image: but as highlighted by the original thread, the navigation between the pyramidal levels shows clear inconsistency which points either to an ordering issue of to the fact some of the IFDs should be treated as separate images. Coming back to the statement above and in agreement with the Aperio specification document, relying on whether IFDs are written using strips and uses a JPEG compression seems like a consistent way to identify these intermediate planes. |
|
This issue has been mentioned on Image.sc Forum. There might be relevant details there: https://forum.image.sc/t/preview-error-when-tcga-svs-image-was-imported/67945/2 |
|
Retested briefly the sample file mentioned in #3757 (comment) with an older version of Bio-Formats (prior to the changes introduced in #3733). In Bio-Formats 6.7.0, the data representation was as follows i.e. 3 series one with pyramidal levels and two ancillary images As demonstrated in #3757 (comment), Bio-Formats 6.10.0, creates an internal representation of this image as a single multi-resolution image with 5 pyramidal levels. This seems definitely more in-line with the internal structure of the file. Importing the file into an OMERO.server 5.6.3 (including Bio-Formats 5.6.1) leads to the file being imported as three images. The second one internally generates a pyramid (as it exceeds the maximum plane dimensions). The first image is usable but the user experience is sub-optimal and reveals the absence of intermediate resolutions:
Importing the file into an development OMERO.server (including the HEAD of Bio-Formats) leads to the file being imported as a single image with no pyramid generation. The thumbnail is broken and the data displayed at low levels of resolution are incorrect as shown in https://forum.image.sc/t/preview-error-when-tcga-svs-image-was-imported/67945
At high-level of resolutions, using the viewport URL to compare equivalent regions on both systems seems to indicate that the data is identical
For this particular sample file, my overall feeling is that
The description of #3764 includes a reference to IFD re-ordering which might be related so possibly we want to reinclude this PR and test it against the two sample files @dgault ? Also quoting another part of the Aperio specification So the expected IFD order seems to be
This seems to be consistent with the two output of |
|
This issue has been mentioned on Image.sc Forum. There might be relevant details there: https://forum.image.sc/t/correct-way-to-convert-svs-slides-for-omero-import/50942/28 |
|
This issue has been mentioned on Image.sc Forum. There might be relevant details there: https://forum.image.sc/t/correct-way-to-convert-svs-slides-for-omero-import/50942/29 |
|
This issue has been mentioned on Image.sc Forum. There might be relevant details there: https://forum.image.sc/t/correct-way-to-convert-svs-slides-for-omero-import/50942/30 |
|
Looked at this again in the context of #4081. Based on that work and #3757 (comment), it looks the problem at this point is down to the thumbnail image only, and specifically the fact that the thumbnail's aspect ratio differs from the other resolutions and the scale factor between the thumbnail and next-largest resolution is different from scale factors between other pairs of adjacent resolutions in the pyramid. A few possible ways forward:
My personal preference is (2) by default, maybe with an option to switch to (1). |
|
Coming back late (apologies) to this issue, my preference would also go to implement proposal (2) with a reader option to fall back to the current behavior. The sub-resolution API does not impose many requirements on the relationship between the consecutive resolutions so none of the options discussed above is fundamentally incorrect. Taking the most extreme layout, a SVS file can be minimally composed of 2 IFDs: the high-resolution and the thumbnail. Without flattening the resolutions, the current SVS reader API would detect such a file as a single image with 2 resolution levels. This representation would be highly unusable for resolution-aware clients which would typically expect pyramidal levels to be downsampled homogeneously alongside each dimension using a predetermiend scale factor (usually 2, 3, 4). To retain the ability to expose the thumbnail IFD and offer some form of backwards compatibility for clients who might be relying on the current behavior, adding a reader-specific option would be fine with me. Alternatively, it might be possible to expose this thumbnail using the |
|
All makes sense. #4081 needs to be merged first, but then it probably makes sense to do this for 7.1.0 or 7.2.0 so we can draw a line under major SVS issues. I've added to the 7.1.0 milestone so we don't forget, but can push to 7.2.0 depending on timelines. |
|
This issue has been mentioned on Image.sc Forum. There might be relevant details there: |
Issue was raised on the forum thread https://forum.image.sc/t/problem-about-opening-some-svs-slides-in-qupath-v0-3-1-bio-formats-6-8-0/61404/15
A sample file was provided on the thread which reproduces the problem. The problem seems to be as a result of changes to the handling of macro and label images in #3733
Using the provided sample file with 6.8.0 you get:
With 6.8.0 and flattened resolutions you get:
With 6.7.0 you get:
The text was updated successfully, but these errors were encountered: