[Insight-users] Can't read Philips dicom data (C. A. Cois)

[Mathieu Malaterre]

On Wed, Sep 17, 2008 at 3:22 AM, Todd Jensen <todd.jensen at ieee.org> wrote:
> From: "C. A. Cois" <cacois.itk at gmail.com>
>
>>I have a data disc with a dicom directory containing IM_###, PS_###,
>>and XX_### files, where ### are integers. The pack-in philips reader
>>can read and display the series, but ITK readers are unable to.  [...]
>> I've heard rumblings
>>about a new philips one file dicom format..could this be it?  Anyone
>>have any ideas?
>
> You may have an enhanced multiframe object. I've been successfully "unenhancing" these with David Clunie's dcuncat tool available with his Dicom3Tools distribution (http://www.dclunie.com/dicom3tools.html).
>
> I used it as follows:
>
> dcuncat -unenhance -of IM_###_ IM_###
>
> The result is a set of files IM_###_1 to IM_###_n, one frame per file, which the ITK DICOM readers handle just fine. Kudos to David Clunie for providing this and just recently updating it to handle large files.

To avoid further misunderstanding;

- GDCM / ITK does support (to some extent) simple Enhanced Multiframe
MR/CT object out of the box, no need to convert whatsoever.
- When you are using dcuncat you will be loosing any Attributes
present in the new Enhanced MR object that was not present in the old
MR Image Storage.
- Worse case scenario is that your Enhanced MR contains a
rescale/slope, which is not required to be supported in the old MR
Image Storage (PS 3.3- 2008).

  I would highly suggest to avoid this 'unenhancing' approach if possible.

What does not work here is the Series filename generator. If you
instanciate it, it means you are trying to create a 4D volume, which
apparently does not work. Please fill in a bug report saying that 4D
volume are not handled properly in the GDCMSeriesFilenames.

If you are only interested in a single volume, then simply instanciate
the FileReader +  GDCMImageIO.

2cts

-- 
Mathieu