dicomParser icon indicating copy to clipboard operation
dicomParser copied to clipboard

Add support for loading DICOM object without PixelData

Open cylien opened this issue 3 years ago • 6 comments

We are implementing to deal with the DICOM WSI. When loading DICOM WSI, where PixelData almost contains multi frames having huge data sizes. Does it possible that when loading a DICOM object providing an option to ignore the PixelData Tag in order for the performance ?

cylien avatar Aug 07 '21 07:08 cylien

I don't know if cornerstone supports loading WSI without PixelData, but if you are looking for an open source pathology viewer in the same spirit as cornerstone you could have a look at Slim.

https://github.com/MGHComputationalPathology/slim

pieper avatar Aug 07 '21 10:08 pieper

My team is developing WSI Server for the functions of the WADO-RS/URI to retrieve a specified frame in a DICOM WSI. The problem is the size of the PixelData is too large to load all frames in memory. for a 1.5GB WSI including over 2 thousand frames requires about 15GB RAM. Thus we are thinking of using dicomParser to get the address index of the all frames to save the use of memory. This is our project: https://github.com/cylab-tw/raccoon

BTW: we are also developing DICOM WSI Viewer. For the development of the DICOM Viewer, dicomParser is excellent.

cylien avatar Aug 07 '21 11:08 cylien

That's really great @cylien, thanks for sharing the links and I'm glad things are working well for you.

If you haven't already seen it, the OHIF viewer has some common elements with your viewer and maybe it could help to share ideas and elements. Similarly some of us have been working on a noSQL DICOMweb server (dicomweb-server) and related technologies. It's good to see the standards-based interoperability.

pieper avatar Aug 10 '21 13:08 pieper

We find the problem is that Test WSI DICOM of the WG 26 locates at:

ftp://medical.nema.org/medical/dicom/Datasets/WG26/Leica_GT450/272320e7-5abb-ccac-8f8b-9c2008f53845_114626/1.3.6.1.4.1.36533.21716722913121316773164147287613518920414871.dcm

In this file, there has a large number of items in the Shared Functional Groups Sequence Attribute Tag (5200,9229), so that the size of the DICOM JSON is approximate over 15 MB that is limited by this reason.

Currently, we use an alternate way to replace dicomParser, i.e., using the dcm2json of the DCMTK to create the whole DICOM JSON, and then delete the (5200,9229) Sequence to reduce the size.

Similarly some of us have been working on a noSQL DICOMweb server (dicomweb-server) and related technologies. It's good to see the standards-based interoperability.

It's great, we will using BlueLight to connect dicomweb-server to validate the functionality of the DICOMWeb.

cylien avatar Aug 11 '21 12:08 cylien

That's an interesting constraint and I guess you'll need to find a workaround on the mongodb side of things. I know that the shared and per-frame functional groups can grow very large for WSI datasets and metadata queries have been a performance issue for other implementations too. Best of luck 👍

pieper avatar Aug 11 '21 12:08 pieper

@cylien You could try setting the untilTag option to x7fe00003 so that it parses everything up to the PixelData. You can see here that there are a few tags after the PixelData that you could miss, but unless you have trailing padding or digital signatures there's probably a low chance that would affect you.

yagni avatar Sep 20 '22 13:09 yagni