# itk js readImageDICOMFileSeries Problem to read big series

**URL:** <https://discourse.itk.org/t/itk-js-readimagedicomfileseries-problem-to-read-big-series/2856>\
**Category:** Uncategorized\
**Created:** [March 19, 2020, 5:30pm UTC](https://discourse.itk.org/t/itk-js-readimagedicomfileseries-problem-to-read-big-series/2856 "2020-03-19T17:30:38Z")\
**Posts on this page:** 19\
**Page:** 1

<div class="post-metadata">

**Author:** ![Athius](https://discourse.itk.org/user_avatar/discourse.itk.org/athius/32/304_2.png) [@Athius](https://discourse.itk.org/u/Athius)\
**Post date:** [March 19, 2020, 5:30pm UTC](https://discourse.itk.org/t/itk-js-readimagedicomfileseries-problem-to-read-big-series/2856/1 "2020-03-19T17:30:38Z")

</div>

Hi everyone,

I try itk.js using this example ([ITK Read Dicom](https://glitch.com/~itk-read-dicom)).  
So I have a NodeJS server and launch a simple webpage to open DICOM Series.  
When I try to load big Dicom Series (more than 700 images), then the loader does not work.

On Chrome console, I obtain this error:

```auto
"Error: Could not read file: /work/11.dcm
    at readImageEmscriptenFSDICOMFileSeries (http://localhost:8081/itk/WebWorkers/ImageIO.worker.js:59:356)
    at readDICOMImageSeries (http://localhost:8081/itk/WebWorkers/ImageIO.worker.js:32:3478)
    at http://localhost:8081/itk/WebWorkers/ImageIO.worker.js:32:3827
    at o (http://localhost:8081/itk/WebWorkers/ImageIO.worker.js:2:2754)
    at http://localhost:8081/itk/WebWorkers/ImageIO.worker.js:2:3342
    at http://localhost:8081/itk/WebWorkers/ImageIO.worker.js:2:3404"

```

I try to uptade the version of itk to 10.2.2 but nothing change. I tried also to open other dicoms with the same error. I open those dicom using python or C++ with no problem at all.

I also tried to use readImageLocalDICOMFileSeries function but I have another error:

```auto
TypeError: fs.readdirSync is not a function
    at eval (/myapp/node_modules/itk/readImageLocalDICOMFileSeries.js:22:21)
    at new Promise (<anonymous>)
    at readImageLocalDICOMFileSeries (/myapp/node_modules/itk/readImageLocalDICOMFileSeries.js:18:11)
    at HTMLInputElement.eval (/myapp/src/index.js:260:78)

```

Is it possible to load those “big” dicoms?  
Thank you

---

<div class="post-metadata">

**Author:** ![matt.mccormick](https://discourse.itk.org/user_avatar/discourse.itk.org/matt.mccormick/32/7_2.png) [@matt.mccormick](https://discourse.itk.org/u/matt.mccormick)\
**Post date:** [March 19, 2020, 5:51pm UTC](https://discourse.itk.org/t/itk-js-readimagedicomfileseries-problem-to-read-big-series/2856/2 "2020-03-19T17:51:06Z")

</div>

Hi Romain,

Are the 700 files from the same volume?

Thanks,  
Matt

---

<div class="post-metadata">

**Author:** ![Athius](https://discourse.itk.org/user_avatar/discourse.itk.org/athius/32/304_2.png) [@Athius](https://discourse.itk.org/u/Athius)\
**Post date:** [March 19, 2020, 5:59pm UTC](https://discourse.itk.org/t/itk-js-readimagedicomfileseries-problem-to-read-big-series/2856/3 "2020-03-19T17:59:15Z")

</div>

Yes. There are from the same Series

---

<div class="post-metadata">

**Author:** ![matt.mccormick](https://discourse.itk.org/user_avatar/discourse.itk.org/matt.mccormick/32/7_2.png) [@matt.mccormick](https://discourse.itk.org/u/matt.mccormick)\
**Post date:** [March 19, 2020, 6:02pm UTC](https://discourse.itk.org/t/itk-js-readimagedicomfileseries-problem-to-read-big-series/2856/4 "2020-03-19T18:02:11Z")

</div>

You may be running out of memory. Performance and memory optimizations are underway for itk.js and the DICOM series reader. I will follow-up when they are released.

---

<div class="post-metadata">

**Author:** ![Athius](https://discourse.itk.org/user_avatar/discourse.itk.org/athius/32/304_2.png) [@Athius](https://discourse.itk.org/u/Athius)\
**Post date:** [March 19, 2020, 6:12pm UTC](https://discourse.itk.org/t/itk-js-readimagedicomfileseries-problem-to-read-big-series/2856/5 "2020-03-19T18:12:30Z")

</div>

Ok great thank you. Do you think if I load the series image by image and send it server side for each slices it will work? The problem of this solution is that on server side I must reconstruct the volume and sort all slices before creating the volume.

---

<div class="post-metadata">

**Author:** ![matt.mccormick](https://discourse.itk.org/user_avatar/discourse.itk.org/matt.mccormick/32/7_2.png) [@matt.mccormick](https://discourse.itk.org/u/matt.mccormick)\
**Post date:** [March 20, 2020, 9:04pm UTC](https://discourse.itk.org/t/itk-js-readimagedicomfileseries-problem-to-read-big-series/2856/6 "2020-03-20T21:04:27Z")

</div>

Possibly. This approach is what I am working towards in the next revision.

---

<div class="post-metadata">

**Author:** ![Athius](https://discourse.itk.org/user_avatar/discourse.itk.org/athius/32/304_2.png) [@Athius](https://discourse.itk.org/u/Athius)\
**Post date:** [March 26, 2020, 2:39pm UTC](https://discourse.itk.org/t/itk-js-readimagedicomfileseries-problem-to-read-big-series/2856/7 "2020-03-26T14:39:46Z")

</div>

I continue to understand this error and I found that the problem occurs also with just two images of my dicom series. I reproduce this error with the itk-vtk-viewer example. Is it possible that the pixel data encoding is at fault?  
I can send you some slices of this series for debugging purpose.

---

<div class="post-metadata">

**Author:** ![matt.mccormick](https://discourse.itk.org/user_avatar/discourse.itk.org/matt.mccormick/32/7_2.png) [@matt.mccormick](https://discourse.itk.org/u/matt.mccormick)\
**Post date:** [March 26, 2020, 9:07pm UTC](https://discourse.itk.org/t/itk-js-readimagedicomfileseries-problem-to-read-big-series/2856/8 "2020-03-26T21:07:21Z")

</div>

If one slice is loaded in the itk-vtk-viewer example, does it load correctly?

---

<div class="post-metadata">

**Author:** ![Athius](https://discourse.itk.org/user_avatar/discourse.itk.org/athius/32/304_2.png) [@Athius](https://discourse.itk.org/u/Athius)\
**Post date:** [March 27, 2020, 8:48am UTC](https://discourse.itk.org/t/itk-js-readimagedicomfileseries-problem-to-read-big-series/2856/9 "2020-03-27T08:48:27Z")

</div>

No I have the same problem with only one slice (I test different slices from this series with the same error)

---

<div class="post-metadata">

**Author:** ![matt.mccormick](https://discourse.itk.org/user_avatar/discourse.itk.org/matt.mccormick/32/7_2.png) [@matt.mccormick](https://discourse.itk.org/u/matt.mccormick)\
**Post date:** [March 27, 2020, 12:10pm UTC](https://discourse.itk.org/t/itk-js-readimagedicomfileseries-problem-to-read-big-series/2856/10 "2020-03-27T12:10:27Z")

</div>

Which scanner generated these images and what is the modality?

---

<div class="post-metadata">

**Author:** ![dzenanz](https://discourse.itk.org/user_avatar/discourse.itk.org/dzenanz/32/1093_2.png) [@dzenanz](https://discourse.itk.org/u/dzenanz)\
**Post date:** [March 27, 2020, 12:54pm UTC](https://discourse.itk.org/t/itk-js-readimagedicomfileseries-problem-to-read-big-series/2856/11 "2020-03-27T12:54:39Z")

</div>

I guess sharing a few slices would be easier.

If they are not already [annonymized](https://www.researchgate.net/post/Best_free_tool_for_DICOM_data_anonymization), see whether annonymization preserves problem-causing “quality”.

---

<div class="post-metadata">

**Author:** ![Athius](https://discourse.itk.org/user_avatar/discourse.itk.org/athius/32/304_2.png) [@Athius](https://discourse.itk.org/u/Athius)\
**Post date:** [March 27, 2020, 2:43pm UTC](https://discourse.itk.org/t/itk-js-readimagedicomfileseries-problem-to-read-big-series/2856/12 "2020-03-27T14:43:42Z")

</div>

It’s a CT scan generated by a GE scanner. I attach you one slice anonymized :[slice\_ano.dcm](https://discourse.itk.org/uploads/short-url/62EhNGLSGRkgXvE8Av4UvIPcwjS.dcm) (201.9 KB)

---

<div class="post-metadata">

**Author:** ![dzenanz](https://discourse.itk.org/user_avatar/discourse.itk.org/dzenanz/32/1093_2.png) [@dzenanz](https://discourse.itk.org/u/dzenanz)\
**Post date:** [March 27, 2020, 3:39pm UTC](https://discourse.itk.org/t/itk-js-readimagedicomfileseries-problem-to-read-big-series/2856/13 "2020-03-27T15:39:26Z")

</div>

Maybe the problem is that it has 32-bit pixel intensities? And that is not needed since the pixel intensities range from -3024 to 1308. Just converting the pixel type to short would save half the memory, even if that is not the problem for loading.

---

<div class="post-metadata">

**Author:** ![Athius](https://discourse.itk.org/user_avatar/discourse.itk.org/athius/32/304_2.png) [@Athius](https://discourse.itk.org/u/Athius)\
**Post date:** [March 27, 2020, 4:41pm UTC](https://discourse.itk.org/t/itk-js-readimagedicomfileseries-problem-to-read-big-series/2856/14 "2020-03-27T16:41:11Z")

</div>

I change the pixel type to short but nothing change unfortunately.

---

<div class="post-metadata">

**Author:** ![Athius](https://discourse.itk.org/user_avatar/discourse.itk.org/athius/32/304_2.png) [@Athius](https://discourse.itk.org/u/Athius)\
**Post date:** [March 31, 2020, 5:14am UTC](https://discourse.itk.org/t/itk-js-readimagedicomfileseries-problem-to-read-big-series/2856/15 "2020-03-31T05:14:58Z")

</div>

I continue to investigate on this problem and found something weird on the code of itk-js in itkDICOMImageSeriesReaderJSBinding.cxx file:

```
Line 487: 
case itk::CommonEnums::IOComponent::LONGLONG:
    {
    typedef itk::VectorImage< signed long, ImageDimension > ImageType;

```

If the IOComponent is a long long, why the ImageType is set to signed long instead of long long?

---

<div class="post-metadata">

**Author:** ![dzenanz](https://discourse.itk.org/user_avatar/discourse.itk.org/dzenanz/32/1093_2.png) [@dzenanz](https://discourse.itk.org/u/dzenanz)\
**Post date:** [March 31, 2020, 1:16pm UTC](https://discourse.itk.org/t/itk-js-readimagedicomfileseries-problem-to-read-big-series/2856/16 "2020-03-31T13:16:18Z")

</div>

I think you found a bug. PR is [here](https://github.com/InsightSoftwareConsortium/itk-js/pull/307). @matt.mccormick

---

<div class="post-metadata">

**Author:** ![matt.mccormick](https://discourse.itk.org/user_avatar/discourse.itk.org/matt.mccormick/32/7_2.png) [@matt.mccormick](https://discourse.itk.org/u/matt.mccormick)\
**Post date:** [March 31, 2020, 1:54pm UTC](https://discourse.itk.org/t/itk-js-readimagedicomfileseries-problem-to-read-big-series/2856/17 "2020-03-31T13:54:32Z")

</div>

This is intentional since JavaScript/WebAssembly/Emscripten does not have full 64-bit integer support.

---

<div class="post-metadata">

**Author:** ![matt.mccormick](https://discourse.itk.org/user_avatar/discourse.itk.org/matt.mccormick/32/7_2.png) [@matt.mccormick](https://discourse.itk.org/u/matt.mccormick)\
**Post date:** [April 13, 2020, 6:14pm UTC](https://discourse.itk.org/t/itk-js-readimagedicomfileseries-problem-to-read-big-series/2856/18 "2020-04-13T18:14:23Z")

</div>

Hi @Athius ,

itk.js 12.2.0 was recently released with improved DICOM support. Please give it a try. Note that the arguments to `readImageDICOMFileSeries` changed recently. Your _slice\_ano.dcm_ reads fine now:

 ![image](https://discourse.itk.org/uploads/default/original/2X/3/3114ccb93c4cae12ed94c4dfee1aaae9abd574d7.jpeg)

Thanks,  
Matt

---

<div class="post-metadata">

**Author:** ![Athius](https://discourse.itk.org/user_avatar/discourse.itk.org/athius/32/304_2.png) [@Athius](https://discourse.itk.org/u/Athius)\
**Post date:** [April 20, 2020, 7:33am UTC](https://discourse.itk.org/t/itk-js-readimagedicomfileseries-problem-to-read-big-series/2856/19 "2020-04-20T07:33:37Z")

</div>

Hi Matt,  
Sorry for this late answer. The reading work fine now! Thank you so much.

For the speed issue, we read the full series client side then split the image data buffer in multiple chunks, compress each chunk then do a base64 and send each chunk (with the chunk size, and the type of the pixels, the orientation matrix, the origin and the spacing) on server side using a websocket to do some treatments (segmentation and other “heavy” operations).