Support for DICOM WSI concatenations

[petroslk]

Hello there! We were wondering if support for DICOM WSI concatenations would be implemented in the future. Some WSI scanners generate those by default and switching is not always straightforward. Thanks a lot for your amazing work!

[jcupitt]

Hi @petroslk,

This would need a chunk of new code, so let's tag this as an enhancement.

This has been discussed on openslide, they'd probably need some new code too. dclunie posted some useful notes, see:

https://github.com/openslide/openslide/issues/511#issuecomment-1774220332

[petroslk]

Hey @jcupitt

Indeed, we noticed that the MergeConcatenationInstances function provided in that issue actually does the trick. We used it to concatenate the 40X .dcm layers into one and read that with vips 8.15.2 compiled with openslide 4.0 and it worked. Perhaps some of this functionality could be ported over. Thanks!

[choosehappy]

Thanks for all your great work in putting together this library -- was really a game changer for us

I'm sorry to ask but - is there any sense of if/where this is on the development roadmap? It has become critical for us to come up with a solution

Our pathology service is entirely digital, accredited, and scans ~ 2,000 WSI a day. Currently, we're deploying in-house digital pathology algorithms into that setting using openslide + DICOM

the scanners produce dicom natively, so that they can be pushed into a shared sectra pacs. Our 3dhistec scanner produces multipart dicom files often, since we have e.g., large prostate double wide slides.

While one could in theory turn off extended offset tables in the scanner (unknown if this actually works, but anyway...) this creates two issues for us in that, (a) the workflow is already accredited, so any software modifications would require a laborious "accreditation change notification" process to ensure that everything continues to work as expected while, (b) we'd be on the hook for saving these hug 14GB files as a single file, making transfer / storage /retreival suboptimal

My understanding is that the purpose of the concatenation and extended offset tables being introduced into the DICOM standard was for exactly this use case - is that correct?

Since it is part of the standard - I would hope it would be part of the roadmap for libraries to take it on - especially because I think in the future most scanners would disable the ability to not use them - but I of course appreciate that being a open-source project (of which I lead many) there are many other factors to take into account : )

Any thoughts would be appreciated!

[fedorov]

@choosehappy I will let @jcupitt and @bgilbert to comment on where this is on the roadmap, or if this is on the roadmap.

But I wanted to add, for the background/awareness, that support of DICOM WSI in OpenSlide was funded from the Imaging Data Commons budget. We determined this was a critical missing piece, and supported this effort. At this point, we exhausted the budget we had available for OpenSlide DICOM WSI development. I cannot tell if/when we may have additional resources to invest into further new development of DICOM-related functionality in OpenSlide.

If this feature is critical for your organization, you may consider contributing it via PR, or allocating resources to for someone (perhaps @jcupitt is available) to help you with this implementation.

I greatly appreciate your feedback, as it is critical for defining what are the features that users need prioritized. We just need to find resources to implement this.

[jcupitt]

Hello @choosehappy, I think (from memory) extended offset tables should work in libdicom 1.1, it's just multipart DICOMs which are not supported.

This seems like a popular and missing feature, so of course we'd like to have it, it's just a question of someone volunteering (or being paid!) to do the work.

[choosehappy]

Thanks for the feedback @jcupitt, certainly appreciate the situation!

I had looked into us doing it ourselves, but its too much of a heavy lift giving our in-house skills/background

or being paid!

Interesting to hear, this could certainly be a possibility – do you have a sense of how this typically works?

i.e., is it paid consulting hours to you or someone on your team? How could we learn more (expected scope, budget, etc)?

[jcupitt]

You could find someone to do the work and I could review and merge it unpaid.

Alternatively, I'm booked until September or so, but I could take the work myself after that. I would guess (just a random guess, we should estimate more carefully before budgeting) a week's work to develop, test, document and integrate, at typical contractor rates.

[choosehappy]

Sounds reasonable to me - let me kick it up the chain...

and thank you : )