[dcmlib] Dicom images produced by ITK

Jean-Pierre Roux Jean-Pierre.Roux at creatis.insa-lyon.fr
Fri Oct 7 13:56:31 CEST 2005


Hi, Mathieu.

I just get Dicom images written by the ITK writer
(I read a .png image, I wrote it as a .dcm image)

>From a strict DICOM point of view, I disagree with some minor details
(probabely nobody in the ITK community cares about them, but a PACS should
do ...)

In the meta elements :

V 0002|0002 [UI]  [Media Storage SOP Class UID] [1.2.840.10008.5.1.4.1.1.2
]  ==> [CT Image Storage]
Since it's a 'modified' image , we should have :
V 0002|0002 [UI]  [Media Storage SOP Class UID] [1.2.840.10008.5.1.4.1.1.7
]  ==> [Secondary Capture Image Storage]

V 0008|0060 [CS]    [Modality] [CT]
Since it's an image 'made out of nothing' we should have :
V 0008|0060 [CS]    [Modality] [OT]
(OT  stands for 'other" : any modality but an existing one
In this particular image, since 0028|0100 [US] [Bits Allocated] = 8, sure
it's NOT a CT image .
A PACS should reject this image as inconsistent.

-->
V 0008|0016 [UI] [SOP Class UID] [1.2.840.10008.5.1.4.1.1.2 ]  ==> [CT
Image Storage]

0008|0016 [SOP Class UID] should be 1.2.840.10008.5.1.4.1.1.7 (seconday
Capture, also)

I read :
V 0020|0052 [UI]   [Frame of Reference UID]
[1.2.826.0.1.3680043.2.1125.1.827313123916.2005100617484383933 ]
Frame Of Reference UID is only meaningfull for a 'Serie', and should refer
to an existing SOP Instance UID.
The best ITK  writter has to do is NOT to write it.

And finally, some strange stuff from the DICOM norm :
The following fields have a type of '2' (the tag is mandatory, but its
value may be missing (?!?)
0x0010, 0x0030 Patient's Birth Date
0x0010, 0x0040 Patient Sex
0x0008, 0x0090 Referring Physician's Name

Could you forward this mail to ITK developpers.
Thx

JP



More information about the Dcmlib mailing list