# itk.js: readImageDICOMFile(Series): wrong componentType with itk.js 13.1.3

**URL:** https://discourse.itk.org/t/itk-js-readimagedicomfile-series-wrong-componenttype-with-itk-js-13-1-3/3477
**Category:** Engineering
**Tags:** dicom, javascript
**Created:** [September 22, 2020, 8:31am UTC](https://discourse.itk.org/t/itk-js-readimagedicomfile-series-wrong-componenttype-with-itk-js-13-1-3/3477 "2020-09-22T08:31:12Z")
**Posts on this page:** 3
**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: [September 22, 2020, 8:31am UTC](https://discourse.itk.org/t/itk-js-readimagedicomfile-series-wrong-componenttype-with-itk-js-13-1-3/3477/1 "2020-09-22T08:31:12Z")

</div>

Hi,  
I tried to load a MRI DICOM series using readImageDICOMFileSeries in javascript. For this, I start from the itk-read-dicom example and update the itk package to the last version (13.1.3) and modify the line:

```javascript
return readImageDICOMFileSeries(null, files)

```

by

```javascript
return readImageDICOMFileSeries(files)

```

I have a memory issue with the new version of itk.js.

When I load just one instance (slice), I see different component type between itk.js 9.2.0 version and itk.js 13.1.3

```auto
// Output for one slice in itk.js 9.2.0
{
    "imageType": {
        "dimension": 3,
        "componentType": "int16_t",
        "pixelType": 1,
        "components": 1
    },
    "name": "Image",
    "origin": [
        -212.871,
        -192.5,
        37.514
    ],
    "spacing": [
        0.751953,
        0.751953,
        0.625
    ],
    "direction": {
        "rows": 3,
        "columns": 3,
        "data": [
            1,
            0,
            0,
            0,
            1,
            0,
            0,
            0,
            -1
        ]
    },
    "size": [
        512,
        512,
        1
    ],
    "data": "-3024,-3024,-3024,-3024,-3024,-3024..."
}

```

```auto
// Output for one slice in itk.js 13.1.3
{
    "imageType": {
        "dimension": 3,
        "componentType": "int32_t",
        "pixelType": 1,
        "components": 1
    },
    "name": "Image",
    "origin": [
        -212.871,
        -192.5,
        37.514
    ],
    "spacing": [
        0.751953,
        0.751953,
        1
    ],
    "direction": {
        "rows": 3,
        "columns": 3,
        "data": [
            1,
            0,
            0,
            0,
            1,
            0,
            0,
            0,
            1
        ]
    },
    "size": [
        512,
        512,
        1
    ],
    "data": "-3024,-3024,-3024,-3024,-3024,-3024..."
}

```

When I open in other sofware (Slicer, ITKSnap), the type of the image is really in int16\_t and not in int32\_t.

Does anyone see this bug?

I can provide in MP one slice of the DICOM.

---

<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: [September 23, 2020, 8:51am UTC](https://discourse.itk.org/t/itk-js-readimagedicomfile-series-wrong-componenttype-with-itk-js-13-1-3/3477/2 "2020-09-23T08:51:07Z")

</div>

I found a difference:  
In the version 9.2, readDicomFileSeries used DCMTK and now, the version 13.1.3 uses GDCM.

---

<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: [September 24, 2020, 2:13pm UTC](https://discourse.itk.org/t/itk-js-readimagedicomfile-series-wrong-componenttype-with-itk-js-13-1-3/3477/3 "2020-09-24T14:13:49Z")

</div>

I continued to investigate this problem and I found something  
I’ve finished investigating: so it’s not a bug, it’s before there was one. Simply put, the data is stored in int16 but there is parameters that indicates the offset of each pixel value: the Recale Intercept and the Recale Slope. Those parameters exist for CT scans so that all values can be put on the Hounsfield scale. As a result, the type of data stored may not be the same as the actual data. This trick is made to optimize the storage space.  
And all of this was explain [here](https://blog.kitware.com/dicom-rescale-intercept-rescale-slope-and-itk/): thank you Matt for this great ticket!