EnhancedMRImageStorage from Philips Achieva 3.2

[Dimitri Papadopoulos]

Dear all,

Partners in a research project have sent us 44 DICOM datasets exported from a Philips Achieva 3T MRI scanner. Version of the Philips software is 3.2. Each dataset is made of 29 files:

  IM_0001  IM_0004  IM_0006  IM_0008  IM_0010
  IM_0012  IM_0014  IM_0016  IM_0018  IM_0021
  IM_0023  IM_0025  PS_0002  PS_0019  XX_0003
  XX_0005  XX_0007  XX_0009  XX_0011  XX_0013
  XX_0015  XX_0017  XX_0020  XX_0022  XX_0024
  XX_0026  XX_0027  XX_0028  XX_0029

* The IM files are EnhancedMRImageStorage images.
* The PS files are GrayscaleSoftcopyPresentationStateStorage images.
* The XX files are RawDataStorage images.

For all datasets, pydicom works fine on some of the files (IM_0001, PS_0002, XX_0003, IM_0004, XX_0005, IM_0006, XX_0007, ...) but bails out on others (IM_0008, XX_0009, XX_0011, ...):

$ python

Python 2.7.3 (default, Sep 26 2013, 20:03:06) 

[GCC 4.6.3] on linux2

Type "help", "copyright", "credits" or "license" for more information.

>>> import dicom

>>> IM_0008 = dicom.read_file('IM_0008')

Traceback (most recent call last):

  File "<stdin>", line 1, in <module>

  File "/usr/lib/python2.7/dist-packages/dicom/filereader.py", line 562, in read_file

    dataset = read_partial(fp, stop_when, defer_size=defer_size, force=force)

  File "/usr/lib/python2.7/dist-packages/dicom/filereader.py", line 511, in read_partial

    stop_when=stop_when, defer_size=defer_size)

  File "/usr/lib/python2.7/dist-packages/dicom/filereader.py", line 303, in read_dataset

    raw_data_element = de_gen.next()

  File "/usr/lib/python2.7/dist-packages/dicom/filereader.py", line 272, in data_element_generator

    seq = read_sequence(fp, is_implicit_VR, is_little_endian, length)

  File "/usr/lib/python2.7/dist-packages/dicom/filereader.py", line 332, in read_sequence

    dataset = read_sequence_item(fp, is_implicit_VR, is_little_endian)

  File "/usr/lib/python2.7/dist-packages/dicom/filereader.py", line 351, in read_sequence_item

    raise IOError, "No tag to read at file position %05x" % fp.tell()

IOError: No tag to read at file position 4d4c180

>>> 

$ 

Is this a known issue? I'm not certain to which extent Enhanced DICOM files are supported but I would expect to at least be able to call dicom.read_file. Should I fill in a bug report? Has anyone else experience with Enhanced DICOM data, especially from Philips Achieva 3.2 machines?

Best,

Dimitri

[Darcy Mason]

Hi Dimitri,

The error indicates that pydicom is expecting to read the start of a sequence item, and there were not enough bytes left in the file.  Is it possible some files were corrupted? Have you tried opening some of the files in question with a DICOM viewer or some other program?

It could be a bug in pydicom, or perhaps the file storage is a bit non-standard. If you can provide a failing file with no confidential information, please create a bug report issue and attach the file there; I'll have a closer look at it.

Darcy

[Dimitri]

Hi Darcy,

The images were produced in another lab. I don't know how they were exported from the Philips console - maybe to a DVD? They were then sent to us by FTP in a tarball or ZIP file. So yes, I cannot exclude some files got corrupted in the process.

Note that other programs such as DCMTK's dcmdump also choke some of the files (maybe the same ones, I'm checking right now). See dcmdump errors: EnhancedMRImageStorage from Philips Achieva. That's indeed suspicious.

Before opening a bug report, I'll look into this again and let you know.

[Dimitri]

Hi Darcy,

I have run DCMTK's dcmdump and a small program based on pydicom on all the DICOM files that were transferred from this specific Philips scanner.

Errors are consistent - errors from dcmdump are actually as superset of errors from pydicom. Therefore this is certainly not a pydicom issue, at least not a basic and isolated pydicom bug. At this point I am unable to tell whether we have received DICOM files as exported (how?) from the Philips scanner, or if the files got somehow corrupted after being exported on their way to our lab. I feel I need to investigate this a little bit further before I can provide useful information on this issue.

Dimitri

[Dimitri]

One last piece of information:

dcm2nii is able to convert all our DICOM files to the NIfTI format. Either it merrily skips some private fields and manages not to get confused by bogus information, or it has better knowledge of DICOM intricacies that are of interest in the case of Philips DICOM files (which is quite possible since the author has tested the software with Philips Intera DICOM and Philips Intera PAR/REC images).

dcm2nii is open source, software, licensed under BSD - although the sources are not easy to find: NITRC: MRIcron: Tool/Resource Filelist

Dimitri

[Dimitri]

After communicating with the lab of origin of the DICOM files and comparing file sizes and checksums, it clearly appears that files were corrupted during the transfer to our lab. I'm sorry about this false alarm.

My conclusion would be that it's a pity that a complex norm like DICOM does not provide checksums like ZIP files for example. It's hard to detect corrupted data.

Dimitri