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

Engineering
,
1

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:

return readImageDICOMFileSeries(null, files)

by

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

// 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..."
}

// 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.

2

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

3

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: thank you Matt for this great ticket!

1 Like