[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