I have to handle 4D ultrasound images. They come from a Philips Ultrasound station. These stations usually generate files in a philips-proprietary format, that can be opened and analysed in Philips QLab Software.

From QLab these images can be exported into DCM format. Usually for one 3D+T image sequence ONE BIG DICOM FILE is generated. These DCM files are not quite standard:

• They do not possess UIDs
• Some relevant information is stored in philips-specific tags in the DCM header :
  1. 3001,1003: z-spacing (in cm, Philips specific)
  2. 0018,602e: y-spacing (in cm)
  3. 0018,602c: x-spacing (in cm)
  4. 0028,0008: dimension time (Philips specific)
  5. 3001,1001: dimension Z (Philips specific)
  6. 0028,0010: dimension Y
  7. 0028,0011: dimension X

When I try to open file in MITK i encounter several problems

• MITK tries to open every .DCM that is in the same directory as well
• Dimensions and spacing are read out wrong. Number of transversal slices is set to number of timesteps. And timesteps is set to 0 (opened as 3D volume). And spacing is always 1,1,1.

The latter problem is propably a caused by the philips specific header tags. The file reader needs to be adjusted to detect if it is a Philips generated DCM file and if so, read out the correct tags for dimensions and spacing.

The Tag "3001,0010,?=Philips3D" can be used to detect philips generated DCM files.

An example file can be found under

G:\home\graser\Philips_DCM_Test\4DTEE.dcm

I wrote to the GDCM Mailing list about that problem and wait for response.

Philips3D US DCM files can now be read with the patch.

I still need to fix: When u open a Philips3D DCM file, do not try to open all other DCM files in the same directory

To support Philips3D DCM files

(In reply to comment #4)

I still need to fix: When u open a Philips3D DCM file, do not try to open all
other DCM files in the same directory

--> fixed as well
see new patch

To support Philips3D DCM files 2

To support Philips3D DCM files 3

a little bit more information about the tags:

<0x0028,0x0011> dimTagX; coloumns || sagittal
<0x3001,0x1001> dimTagZ; (Philips specific) transversal
<0x0028,0x0010> dimTagY; // rows || coronal
<0x0028,0x0008> dimTagT;

<0x0018,0x602c> spaceTagX;
<0x0018,0x602e> spaceTagY;
<0x3001,0x1003> spaceTagZ; // (Philips specific)

<0x0018,0x6024> physicalTagX;
<0x0018,0x6026> physicalTagY;
<0x3001,0x1002> physicalTagZ; // (Philips specific)

I found a small bug, causing different behaviour in release and debug mode. Fixed it and created Patch Number 3

I just marked your old patches obsolete, this keeps the attachment list readable.

Solution looks good for me. You could do the next author a favor and split up the long if-else block in mitkDicomSeriesReader.txx into multiple methods.

BTW, you did not mention the most important part of testing in the change request: does the code still load "normal" DICOM data as before? Actually, nobody would care for newly introduced code if it leaves all existing code working.

[SVN revision 28684]
FIX (#6397): Philips3D Ultrasound DCM files are now supported.

Solution looks good for me. You could do the next author a favor and split up
the long if-else block in mitkDicomSeriesReader.txx into multiple methods.

I shortened it.

BTW, you did not mention the most important part of testing in the change
request: does the code still load "normal" DICOM data as before?

"normal" behaviour is the same.

[SVN revision 28688]
COMP (#6397): minimally different type definitions and prefix instead of postfix operator++
Makes code compile with Linux/ITK3.20/GDCM2

(In reply to comment #14)

[SVN revision 28688]
COMP (#6397): minimally different type definitions and prefix instead of
postfix operator++
Makes code compile with Linux/ITK3.20/GDCM2

I needed to change "UCHAR" to "unsigned char", because my setup did not know that define/constant. Also I got a complaint about the "iterator++" and changed it into "++iterator".

These changes should do no harm on other platforms. However, if you know, where this UCHAR definition came from, we might use that for Linux as well -- probably only some namespace missing?!

yes, still works with windows. The UCHAR typedef came from a windows file WinDef.h, so it is better how u changed it.

Works fine now

Spacing is not quite right. Apparently milimeters are used, where centimeters
should have been used

In the Philips3D Dicom files, the spacing values are usually measured in centimeters.

The Tags
<0x0018,0x6024> (for x)
<0x0018,0x6026> (for y)
<0x3001,0x1002> (for z)
describe the measuring unit for the different spacings. If there is the value "3", this means, it is centimeters.
Since all Philips3D files, I encounterd are measured in centimeters, I do not know, if there is any other possible value for these tags.

The ITK Image Spacing is in milimteres, so I have to multiply the spacing values from the dicom header by 10 (if it is centimeters). I added an if-query for that.

Also I changed the index of the itk image to 0,0,0. Before, it was filled with the wrong values.

Ok, since this is special code for handling special ultrasound images.

However, I strongly suggest that you plan how to integrate this with "normal" DICOM loading code. Perhaps you see a solution that uses most of the normal code but makes use of some private data dictionary entries?

Esp. your handling of image origin is dangerous, because your mitk::Image will now most certainly be placed at the wrong position in space. In the result, any measurements will be related to wrong positions. Should you ever (in the future) load Phillips data correctly, the measurements might not fit the images anymore.

T3700 will create a simple testing infrastructure for DICOM loading. Implementing a test case for Phillips data would be helpful for ensuring this feature is actually working.

[9d626c]: Merge branch 'bug-6397-PhilipsDicom'

Merged commits:

2011-03-30 16:40:00 Bastian Graser [141097]
Corrected spacing units (cm and mm)

In the Philips3D Dicom files, the spacing values are usually measured in centimeters.

The Tags
<0x0018,0x6024> (for x)
<0x0018,0x6026> (for y)
<0x3001,0x1002> (for z)
describe the measuring unit for the different spacings. If there is the value "3", this means, it is centimeters.
Since all Philips3D files, I encounterd are measured in centimeters, I do not know, if there is any other possible value for these tags.

The ITK Image Spacing is in milimteres, so I have to multiply the spacing values from the dicom header by 10 (if it is centimeters). I added an if-query for that.

Also I changed the index of the itk image to 0,0,0. Before, it was filled with the wrong values.