Is DICOM image in mesa test conform to standard ?
Arno Wilhelm
when doing some MESA tests (see
http://ihewiki.wustl.edu/wiki/index.php/MESA/Image_Manager#Image_Manager_Test_401:_Modalities_in_Study)
we have run into a problem with a dicom image used in the tests
(CR1S1IM1.dcm).
There exist the control character 0x9F in the ImageComments field
(0020,4000).
Reading the dicom standard 08-05pu.pdf Section 6 I found out that
characters outside the default charcter set (=ascii) have to be
indicated by the 'Specific character set attribute' (0008,0005) and
that control characters from the C1 set shall not be used at all (see
page 18).
Whenever I try to convert the image to xml with the dcm2xml utility I
get following error message:
> ./dcm2xml.exe error.dcm
dcm2xml: error: (0008,0005) Specific Character Set absent but extended
characters used in file: error.dcm
When adding any extended charset with the '+Ca' option to dcm2xml the
conversion to xml succeeds.
Since the character is there and no specific character set is defined
I wonder whether this specific DICOM image conforms to the DICOM
standard ? Or do I misinterpret the standard here ?
thanks in advance,
Arno Wilhelm
P.S.:
Here is the dump of the dicom file:
# Dicom-File-Format
# Dicom-Meta-Information-Header
# Used TransferSyntax: LittleEndianExplicit
(0002,0000) UL 28 # 4, 1
MetaElementGroupLength
(0002,0010) UI =LittleEndianExplicit # 20, 1
TransferSyntaxUID
# Dicom-Data-Set
# Used TransferSyntax: LittleEndianExplicit
(0008,0008) CS [ORIGINAL PRIMARY] # 16, 1
ImageType
(0008,0012) DA [19950720] # 8, 1
InstanceCreationDate
(0008,0013) TM [093508.0000] # 12, 1
InstanceCreationTime
(0008,0016) UI =ComputedRadiographyImageStorage # 26, 1
SOPClassUID
(0008,0018) UI [1.2.392.200036.9125.0.19950720093509] # 36, 1
SOPInstanceUID
(0008,0020) DA (no value available) # 0, 0
StudyDate
(0008,0022) DA [19881129] # 8, 1
AcquisitionDate
(0008,0030) TM (no value available) # 0, 0
StudyTime
(0008,0032) TM [110800.0000] # 12, 1
AcquisitionTime
(0008,0050) SH [FUJI95701] # 10, 1
AccessionNumber
(0008,0060) CS [CR] # 2, 1
Modality
(0008,0070) LO [FUJI PHOTO FILM CO. LTD.] # 24, 1
Manufacturer
(0008,0080) LO [KANAGAWA C.C.] # 20, 1
InstitutionName
(0008,0090) PN (no value available) # 0, 0
ReferringPhysiciansName
(0008,1090) LO [CR201] # 6, 1
ManufacturersModelName
(0010,0010) PN [TANAKA^HANAKO] # 14, 1
PatientsName
(0010,0020) LO [FUJI00001] # 10, 1
PatientID
(0010,0030) DA [19250824] # 8, 1
PatientsBirthDate
(0010,0040) CS [F] # 2, 1
PatientsSex
(0018,0015) CS [ABDOMEN] # 8, 1
BodyPartExamined
(0018,1260) SH [ST] # 2, 1
PlateType
(0018,1261) LO [2] # 2, 1
PhosphorType
(0018,1400) LO [[ ]] # 20, 1
AcquisitionDeviceProcessingDescription
(0018,1401) LO [00] # 2, 1
AcquisitionDeviceProcessingCode
(0018,1402) CS [PORTRAIT] # 10, 1
CassetteOrientation
(0018,1403) CS [10INX12IN] # 10, 1
CassetteSize
(0018,5101) CS [AP] # 2, 1
ViewPosition
(0018,6000) DS [438] # 4, 1
Sensitivity
(0020,000d) UI [1.2.392.200036.9125.0.198811291108.7] # 36, 1
StudyInstanceUID
(0020,000e) UI [1.2.392.200036.9125.0.198811291108.7] # 36, 1
SeriesInstanceUID
(0020,0010) SH (no value available) # 0, 0
StudyID
(0020,0011) IS (no value available) # 0, 0
SeriesNumber
(0020,0013) IS [7] # 2, 1
InstanceNumber
(0020,4000) LT [\ Y" 566] # 12, 1
ImageComments
(0028,0002) US 1 # 2, 1
SamplesPerPixel
(0028,0004) CS [MONOCHROME1] # 12, 1
PhotometricInterpretation
(0028,0010) US 2010 # 2, 1 Rows
(0028,0011) US 1670 # 2, 1
Columns
(0028,0100) US 16 # 2, 1
BitsAllocated
(0028,0101) US 10 # 2, 1
BitsStored
(0028,0102) US 9 # 2, 1
HighBit
(0028,0103) US 0 # 2, 1
PixelRepresentation
(0028,1050) DS [550] # 4, 1
WindowCenter
(0028,1051) DS [1024] # 4, 1
WindowWidth
(2010,0100) CS [WHITE] # 6, 1
BorderDensity
(7fe0,0010) OW
0000\0000\0000\0000\0000\0000\0000\0000\0000\0000\0000\0000\0000... #
6713400, 1 PixelData
LEADTOOLS
> we have run into a problem with adicomimage used in the tests
> (CR1S1IM1.dcm).
> There exist the control character 0x9F in the ImageComments field
> (0020,4000).
Hello Arno,
You are correct. If no character set is defined in tag (0008,0005),
then any DICOM reader (or converter in your case) will assume that
this dataset uses the basic graphic set.
However, if there was no special character used in the dataset, the
DICOM reader will (mostly) open it correctly, but you will get an
error only when special characters used. The DICOM reader will also
ignores the non-basic character set if it only opens the pixel data
within a data set and not the tags.
Keep in mind that this will only affect data set strings that contain
characters (like patient name, patient ID, manufacturer, etc).
This means, the file itself does not violate the DICOM standard, and
if the viewers are not required to display that particular item
correctly, then they should open the file.
Our toolkit (http://www.leadtools.com/) can be used to parse a DICOM
data set and retrieve the exact binary data from any item if you need
it. There's a free evaluation edition if you you'd like to try it.
Arno Wilhelm
thanks for your answer!
> This means, the file itself does not violate the DICOM standard, and
> if the viewers are not required to display that particular item
> correctly, then they should open the file.
If I understand you correctly:
The usage of the character 0x9F which represents the control character
'Application Program Command' from the C1 set (see
http://en.wikipedia.org/wiki/C0_and_C1_control_codes) does not violate
the DICOM standard, even when in the DICOM standard (08-05pu.pdf page
18) it says:
"The Control Character set C0 shall be invoked in CL and the Graphic
Character sets G0 and G1 in GL
and GR respectively. Only some Control Characters from the C0 set are
used in DICOM (see Section
6.1.3), and characters from the C1 set shall not be used." ?
Another important question is, how an application should react when it
has to deal with an character that does not conform to the dicom
standard?
Should it ignore the offending part and only give out a warning, or
should it refuse to deal with the non-conforming DICOM document at
all ?
greetings,
Arno Wilhelm
David Clunie
It is definitely a violation of the DICOM standard; no question
about it.
You cannot use bytes in strings that are not permitted by the
character set, default or otherwise.
That said, it does not help the users to do anything other than
ignore the bad character, as most applications would.
David
Arno Wilhelm
thanks for clarifying this point - it's just a we expected it to be.
So we will have a way to workaround this problem ....
Arno