Read different series of dicom

Beginner Questions
,
1

Hi everyone,
I’ve got an issue when loading some dicom files using itk-wasm, in the past I load the uploaded files through readImageDICOMFileSeries, it worked fine when there is just a single serie.
But some of the dicoms are mixed with different series, e.g. one series is a summary of 256 * 256 * 1 sized image with component 3 and othes have size of 800 * 800 * 1 with component 1, and the 256 * 256 one might be the first, the last or some other order to be imported. Here are some results for different imports and setups:
1. The image of 3 components is the first file to be imported, in this situation the error ReadImageDICOMFileSeries.umd.js:9 Only one pixel component is currently supported. Image pixel components: 3 will always show not matter singleSortedSeries param is true or false.
2. The image of 3 components is not the first and singleSortedSeries is set to false, in this situation the correct ct data will not be read, result will be only the 3 component one.
3. The image of 3 components is not the first and singleSortedSeries is set to true, in this situation the correct ct data can be read.

I can read the single file information with readImageFile, but since it’s not ordered, if I read it one by one, the error WebAssembly.instantiate(): Out of memory will show if files are big enough.

How should I handle this correctly to get the different series info? The source files are from different scan machines so the names of the files and the order can not be changed.

regards,
Xoz

2

I’ve made a mistake that I didn’t pass the worker to next readImageFile call, when it is passed the out of memory situation will not present, the readImageFile can work properly.

3

Hi @Xoz ,

Welcome to the ITK community! :sun_with_face:

A note – the updated DICOM package is now at @itk-wasm/dicom.

The readDicomTags function can be used to help identify the different series.

2 Likes
4

Hi @matt.mccormick ,
I’ve met a problem that when reading dicom files from some devices, the readImageFile throws an error ‘No DICOM magic number found, but the file appears to be DICOM without a preamble’, it seems that the dicom files lost some part called preamble, but it can be display in 3d sclicer correctly, should I manully add the lost part to the file?

I’ve also done update itk to the newest version to check if this could be solved but find readImageFile deprecated, the error log tolds me to use new one from @itk-wam/image-io, but that module does not have a function exported which named with that. I’ve found a readImage function, but when I run it to replace the old readImageFile(params changed) like this:

import { readImage } from '@itk-wasm/image-io'
  ...
// in an async func, file is an input File given by an input element
{
    ...
    const imageResult = await readImage(file, { webWorker: null })
    ....
}

The promise keeps pending at this state and will not return anything. The readDicomTags from module dicom still have the same problem.

Did I miss anything important? The document for web io api is still the older version one at https://wasm.itk.org/en/latest/typescript/browser_io.html

regards,
Xoz

5

Hi @Xoz ,

Just a note that there are improvements in progress in handling the dicom preamble in the upcoming ITK 5.4.

Yes, a dicom preamble should be in dicom files - you may want to fix the file or how it was generated.

Did I miss anything important? The document for web io api is still the older version one at Web Browser Input/Output - ITK-Wasm documentation

The docs are currently being updated.

The interface has been simplified and changed. Notes can be found in the migration guide and breaking changes log.

The readImage interface in @itk-wasm/image-io is documented here. This link can be found on the packages page.

Essentially, you want:

const { image } = await readImage(file)

And the @itk-wasm/dicom docs are here.

I plan to provide a high level interface in the dicom package that works with all types of dicom object types over the next few months.

1 Like
6

Thanks matt, I’ll check it again to find out the reason why async functions did not work

1 Like