DICOM WSI from Aperio 450 not visible in SLIM Viewer

[nwey]

Some Aperio files use compression type 33003. Images using this compression need to be decoded as a JPEG 2000 codestream. For 33003: YCbCr format, possibly with a chroma subsampling of 4:2:2.
Is it possible to view this WSI in the SLIM viewer? We could not view original DICOM files from both, Roche Scanner DP200 and Aperio Scanner 450, in the SLIM viewer.

[fedorov]

@nwey thanks a lot for the report! Is there any chance you could share a de-identified image (or a "phantom" slide scan that would not contain any patient information) that we could use to replicate this issue? Without a sample, I personally am not sure how one would approach debugging this.

@dclunie do you have any thoughts about what might be going on here?

[fedorov]

Per feedback from @hackermd, resolution of #122 might help with debugging this problem.

[dclunie]

SLIM supports the J2K images that we currently have in IDC (which were converted from SVS 33003 or 33005), though that is not to say that all J2K images will necessarily work, since there are many combinations of parameters possible and not all are supported by every codec.

I recall that @hackermd did some testing with Leica GT450 images (which from the current production release of the device are not TILED_FULL, but rather use PFFG sequence items to describe tile locations), so that should not be a factor, but could be. I think what he tested from the GT450 were all JPEG rather than J2K though. I wasn't aware that the GT450 produced J2K since the clinical release is supposed to be JPEG, but perhaps a research release can, like its predecessors.

@nwey as @fedorov suggested, the best way to check on our end is for you to send us some samples of what doesn't work, from both Leica and Roche scanners, and perhaps @CPBridge can take a look.

PS. @nwey, when you say "could not view", can we assume you mean refused to show them at all, rather than showed something that was incorrectly rendered?

[nwey]

Hi, where we can provide the data. Do you have a FTP server or is it ok if I send you a link for the download? Best Norbert Von: David Clunie ***@***.***> Gesendet: Donnerstag, 30. März 2023 14:24 An: ImagingDataCommons/slim ***@***.***> Cc: Wey Norbert ***@***.***>; Mention ***@***.***> Betreff: [EXTERN] Re: [ImagingDataCommons/slim] DICOM WSI from Aperio 450 not visible in SLIM Viewer (Issue #145) SLIM supports the J2K images that we currently have in IDC (which were converted from SVS 33003 or 33005), though that is not to say that all J2K images will necessarily work, since there are many combinations of parameters possible and not all are supported by every codec. I recall that @hackermd<https://github.com/hackermd> did some testing with Leica GT450 images (which from the current production release of the device are not TILED_FULL, but rather use PFFG sequence items to describe tile locations), so that should not be a factor, but could be. I think what he tested from the GT450 were all JPEG rather than J2K though. I wasn't aware that the GT450 produced J2K since the clinical release is supposed to be JPEG, but perhaps a research release can, like its predecessors. @nwey<https://github.com/nwey> as @fedorov<https://github.com/fedorov> suggested, the best way to check on our end is for you to send us some samples of what doesn't work, from both Leica and Roche scanners, and perhaps @CPBridge<https://github.com/CPBridge> can take a look. PS. @nwey<https://github.com/nwey>, when you say "could not view", can we assume you mean refused to show them at all, rather than showed something that was incorrectly rendered? — Reply to this email directly, view it on GitHub<#145 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AZD66R6KLQAVRWTJSATMNYLW6V3OLANCNFSM6AAAAAAWKGFJBY>. You are receiving this because you were mentioned.Message ID: ***@***.******@***.***>>

[dclunie]

@nwey a link would be fine

[fedorov]

@nwey I did receive your sample that you sent via email - we are all set in that regard. I will share it with @dclunie and @hackermd. Sorry, I just saw this discussion now.

[hackermd]

@nwey thank you for your interest in Slim and for bringing this issue to our attention. It appears that you are asking three questions:

1. Does Slim support decoding of JPEG 2000 encoded frames with different photometric interpretation and different chroma subsampling?
2. Does Slim support DICOM objects generated by the Leica Aperio GT 450 scanner?
3. Does Slim support DICOM objects generated by the Roche Tissue Diagnostics DP 200 scanner?

Questions 1-2 are potentially related, as tiles in SVS files with compression type "33003" are JPEG 2000 compressed and DICOM objects generated by the Leica Aperio GT 450 may include frames that were compressed this way.

However, I suggest considering the three questions separately:

Re 1. As @dclunie mentioned, we have converted several SVS files with compression types 33003 and 33005 into DICOM files for the IDC and could successfully display them in Slim. Slim uses the OpenJPEG library to decode JPEG 2000 compressed image files (using WebAssembly) and in principle supports decoding of JPEG 2000 compressed images with different subsampling factors. However, as @dclunie said, JPEG 2000 is quite flexible and complex and we haven't tested all eventualities.

Re 2: We have only had limited access to DICOM objects generated by Leica Aperio GT 450 scanners. As @dclunie pointed out, these objects have TILED_SPARSE rather than TILED_FULL. However, that should not be an issue, since Slim supports both dimension organization types. As part of the last DICOM WG-26 Connectathon, we uncovered several standard conformity issues with DICOM objects generated by the Leica scanner and I therefore assume that the issue is due to the data.

Re 3: We tested several DICOM objects generated by Roche Tissue Diagnostics DP 200 and DP 600 scanners during several of DICOM WG-26 Connectathons. These files conformed with the standard and all rendered successfully in Slim. One of the series is included in our public Slim demo (see here).

Thank you for sharing example images with @fedorov. This will be helpful to get to the bottom of the issues you are experiencing. In general, I recommend the following:

• Validate the files for conformity with the DICOM standard using the dciodvfy tool. If the files are in violation of the standard, there may not be much Slim can do. If they conform to the standard, then we will need to debug Slim.
• Provide a detailed description of what doesn't work. To this end, one can take a look into the developer console to see if there are any error messages. We have been working on improving error handling and reporting in Slim (Handle errors globally with Error Middleware and React Error Boundary #134). Moving forward, this should significantly simplify debugging and enable users to understand why a given image fails to display.

[dclunie]

The images that were sent turned out to be JPEG, not J2K, BTW.

[fedorov]

@hackermd if you let me know what google account you are using these days, I will give you access to the sample shared.

For the sake of completeness, the sample is in this bucket: gs://slim-external-testing.

[fedorov]

I tried loading the sample provided and hit the errors below. @cgorman are you available to investigate this? I can add you to the DICOM store that has the sample for testing.

[hackermd]

Can you please try with the latest v0.13.0? That version now includes the debug information and error reporting features.

[cgorman]

@fedorov Could you please provide access for my mgh.harvard.edu account to the bucket gs://slim-external-testing? I'd like to test something out with the original files.