Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Element from group 2 being used in DataSet
912 views
Skip to first unread message
Mathieu Malaterre
Jan 29, 2016, 3:16:50 AM1/29/16
to
Here is an interesting case:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=753809#85
Or directly:
https://bugs.debian.org/cgi-bin/bugreport.cgi?msg=85;bug=753809;att=1;filename=2.dcm
The file starts with:
$ dcmdump 2.dcm
# Dicom-File-Format
# Dicom-Meta-Information-Header
# Used TransferSyntax: Little Endian Explicit
(0002,0000) UL 216 # 4, 1 FileMetaInformationGroupLength
(0002,0001) OB 00\01 # 2, 1 FileMetaInformationVersion
(0002,0002) UI =ComputedRadiographyImageStorage # 26, 1 MediaStorageSOPClassUID
(0002,0003) UI [1.2.276.0.7230010.3.1.4.2831160242.3411.1400154379.583031] # 58, 1 MediaStorageSOPInstanceUID
(0002,0010) UI =LittleEndianImplicit # 18, 1 TransferSyntaxUID
(0002,0012) UI [1.2.276.0.7230010.3.0.3.6.0] # 28, 1 ImplementationClassUID
(0002,0013) SH [OFFIS_DCMTK_360] # 16, 1 ImplementationVersionName
(0002,0016) AE [GNUMEDLH] # 8, 1 SourceApplicationEntityTitle
# Dicom-Data-Set
# Used TransferSyntax: Little Endian Implicit
(0002,0003) UI [1.2.276.0.7230010.3.1.4.2831160242.3411.1400154379.583031] # 58, 1 MediaStorageSOPInstanceUID
(0008,0000) UL 466 # 4, 1 GenericGroupLength
Some open-source implementation(s) did allow that happily while:
http://dicom.nema.org/medical/dicom/current/output/chtml/part10/chapter_7.html#para_c820193f-7a41-4470-a0f4-98b88433b403
states:
[...]
Values of all Tags (0002,xxxx) are reserved for use by this Standard
and later versions of DICOM. Data Elements with a group of 0002 shall
not be used in data sets other than within the File Meta Information.
[...]
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=753809#85
Or directly:
https://bugs.debian.org/cgi-bin/bugreport.cgi?msg=85;bug=753809;att=1;filename=2.dcm
The file starts with:
$ dcmdump 2.dcm
# Dicom-File-Format
# Dicom-Meta-Information-Header
# Used TransferSyntax: Little Endian Explicit
(0002,0000) UL 216 # 4, 1 FileMetaInformationGroupLength
(0002,0001) OB 00\01 # 2, 1 FileMetaInformationVersion
(0002,0002) UI =ComputedRadiographyImageStorage # 26, 1 MediaStorageSOPClassUID
(0002,0003) UI [1.2.276.0.7230010.3.1.4.2831160242.3411.1400154379.583031] # 58, 1 MediaStorageSOPInstanceUID
(0002,0010) UI =LittleEndianImplicit # 18, 1 TransferSyntaxUID
(0002,0012) UI [1.2.276.0.7230010.3.0.3.6.0] # 28, 1 ImplementationClassUID
(0002,0013) SH [OFFIS_DCMTK_360] # 16, 1 ImplementationVersionName
(0002,0016) AE [GNUMEDLH] # 8, 1 SourceApplicationEntityTitle
# Dicom-Data-Set
# Used TransferSyntax: Little Endian Implicit
(0002,0003) UI [1.2.276.0.7230010.3.1.4.2831160242.3411.1400154379.583031] # 58, 1 MediaStorageSOPInstanceUID
(0008,0000) UL 466 # 4, 1 GenericGroupLength
Some open-source implementation(s) did allow that happily while:
http://dicom.nema.org/medical/dicom/current/output/chtml/part10/chapter_7.html#para_c820193f-7a41-4470-a0f4-98b88433b403
states:
[...]
Values of all Tags (0002,xxxx) are reserved for use by this Standard
and later versions of DICOM. Data Elements with a group of 0002 shall
not be used in data sets other than within the File Meta Information.
[...]
Jörg Riesmeier
Jan 29, 2016, 5:05:32 AM1/29/16
to
Hi Mathieu,
that's why dcmdump (the command line tool from the DCMTK) has the following options:
parsing of file meta information:
+ml --use-meta-length use file meta information group length (default)
-ml --ignore-meta-length ignore file meta information group length
So by default, the tool trusts the value of the FileMetaInformationGroupLength but it can be ignored, which means that the DICOM parser checks for all elements from group 0x0002 at the beginning of the dataset.
In any case, a warning is reported if the length is apparently incorrect:
W: DcmMetaInfo: Group Length of Meta Information Header has incorrect value
Regards,
Jörg
that's why dcmdump (the command line tool from the DCMTK) has the following options:
parsing of file meta information:
+ml --use-meta-length use file meta information group length (default)
-ml --ignore-meta-length ignore file meta information group length
So by default, the tool trusts the value of the FileMetaInformationGroupLength but it can be ignored, which means that the DICOM parser checks for all elements from group 0x0002 at the beginning of the dataset.
In any case, a warning is reported if the length is apparently incorrect:
W: DcmMetaInfo: Group Length of Meta Information Header has incorrect value
Regards,
Jörg
Mathieu Malaterre
Jan 29, 2016, 7:36:54 AM1/29/16
to
The warning message is incorrect if you consider that the duplicate group 2 element has been sent using implicit transfer syntax, in which case it cannot possibly be part of File Meta Header.
Furthermore this the elements are actually duplicated, how should the group length be computed...
Neat DICOM sample right :)
Jörg Riesmeier
Jan 29, 2016, 9:30:44 AM1/29/16
to
You are right. For my previous posting, I haven't checked the sample file "2.dcm" but a different one. In fact, no warning is reported by dcmdump since the DICOM file can be parsed correctly (on this level). However, it probably makes sense to report a warning for all DICOM elements with invalid attribute tags, both for the file meta information header and the dataset. Currently, the warning only occurs for the meta header ("DcmMetaInfo: Invalid Element <attribute-tag> found in Meta Information Header"). I'll change this...
Thanks for pointing this out.
Regards,
Jörg
Thanks for pointing this out.
Regards,
Jörg
Jörg Riesmeier
Jan 29, 2016, 9:37:03 AM1/29/16
to
By the way, you can also use the following dcmconv option to get rid of the faulty (0002,0003) in the DICOM dataset:
other processing options:
-ig --no-invalid-groups remove elements with invalid group number
Regards,
Jörg
other processing options:
-ig --no-invalid-groups remove elements with invalid group number
Regards,
Jörg
David Clunie
Jan 31, 2016, 9:26:02 AM1/31/16
to
I agree with Mathieu. This is an invalid DICOM
file, so the bug is in the source system, not the
recipient.
The error is caused by the (0002,0003) data element being
repeated:
- once within the meta information header (within the length
specified by group length (0002,0003))
- once at the beginning of the data set
which can be interpreted as being incorrect in various
ways:
- group 0002 data elements may not occur outside the meta
information header, as Mathieu points out
- data elements may not be repeated
- data elements must be in ascending numerical order
Since the meta information is encoded in explicit VR and
the data set in implicit VR, the two copies of (0002,0003)
are encoded slightly differently, but they do contain the
same value.
I mention this because it explains why toolkits behave
differently with this illegal file (as Mathieu and Jörg
have discussed):
- those that determine the end of the meta information
header based on the (mandatory) group length of group
0002 may switch transfer syntax from explicit to implicit
before the offending tag and read it, and then may or
may not complain about its presence being illegal
(duplicate or out of order), or may just silently
ignore it
- those that use the change of group number from 0002 to
something higher to detect the end of the meta header may
not read the offending implicit VR encoded extra out of
order group 0002 data element correctly if they try to
parse it as explicit VR, and get out of sync
The Implementation Version Name in the meta information header
says "OFFIS_DCMTK_360", but dcmtk doesn't make this kind
of error, as far as I know, so it would be good to know what
system actually encoded this bad DICOM file.
David
% andump debian_753809_badmetaelement.dcm
(0x0002,0x0000) UL File Meta Information Group Length VR=<UL> VL=<0x0004> [0x000000d8]
(0x0002,0x0001) OB File Meta Information Version VR=<OB> VL=<0x0002> [0x00,0x01]
(0x0002,0x0002) UI Media Storage SOP Class UID VR=<UI> VL=<0x001a> <1.2.840.10008.5.1.4.1.1.1>
(0x0002,0x0003) UI Media Storage SOP Instance UID VR=<UI> VL=<0x003a> <1.2.276.0.7230010.3.1.4.2831160242.3411.1400154379.583031>
(0x0002,0x0010) UI Transfer Syntax UID VR=<UI> VL=<0x0012> <1.2.840.10008.1.2>
(0x0002,0x0012) UI Implementation Class UID VR=<UI> VL=<0x001c> <1.2.276.0.7230010.3.0.3.6.0>
(0x0002,0x0013) SH Implementation Version Name VR=<SH> VL=<0x0010> <OFFIS_DCMTK_360 >
(0x0002,0x0016) AE Source Application Entity Title VR=<AE> VL=<0x0008> <GNUMEDLH>
(0x0002,0x0003) UI Media Storage SOP Instance UID VR=<UN> VL=<0x003a> [0x31,0x2e,0x32,0x2e,0x32,0x37,0x36,0x2e,0x30,0x2e,0x37,0x32,0x33,0x30,0x30,0x31,0x30,0x2e,0x33,0x2e,0x31,0x2e,0x34,0x2e,0x32,0x38,0x33,0x31,0x31,0x36,0x30,0x32,0x34,0x32,0x2e,0x33,0x34,0x31,0x31,0x2e,0x31,0x34,0x30,0x30,0x31,0x35,0x34,0x33,0x37,0x39,0x2e,0x35,0x38,0x33,0x30,0x33,0x31,0x00]
(0x0008,0x0000) UL Group Length VR=<UL> VL=<0x0004> [0x000001d2]
(0x0008,0x0005) CS Specific Character Set VR=<CS> VL=<0x000a> <ISO_IR 100>
...
% dcdump -ignoreoutofordertags debian_753809_badmetaelement.dcm
Warning - Tags out of order - trailing garbage, wrong transfer syntax, or not valid DICOM
(0x0002,0x0003) UI Media Storage SOP Instance UID Error - Tag read failed - Implicit VR encoding even though supposed to be explicit
Warning - Bad group length - Group 0x2 specified as 0xd8 actually 0x11a
Error - Dicom dataset read failed
(0x0002,0x0000) UL File Meta Information Group Length VR=<UL> VL=<0x0004> [0x000000d8]
(0x0002,0x0001) OB File Meta Information Version VR=<OB> VL=<0x0002> [0x00,0x01]
(0x0002,0x0002) UI Media Storage SOP Class UID VR=<UI> VL=<0x001a> <1.2.840.10008.5.1.4.1.1.1>
(0x0002,0x0003) UI Media Storage SOP Instance UID VR=<UI> VL=<0x003a> <1.2.276.0.7230010.3.1.4.2831160242.3411.1400154379.583031>
(0x0002,0x0003) UI Media Storage SOP Instance UID VR=<UI> VL=<0x003a> <1.2.276.0.7230010.3.1.4.2831160242.3411.1400154379.583031>
(0x0002,0x0010) UI Transfer Syntax UID VR=<UI> VL=<0x0012> <1.2.840.10008.1.2>
(0x0002,0x0012) UI Implementation Class UID VR=<UI> VL=<0x001c> <1.2.276.0.7230010.3.0.3.6.0>
(0x0002,0x0013) SH Implementation Version Name VR=<SH> VL=<0x0010> <OFFIS_DCMTK_360 >
(0x0002,0x0016) AE Source Application Entity Title VR=<AE> VL=<0x0008> <GNUMEDLH>
(0x0008,0x0000) UL Group Length VR=<UL> VL=<0x0004> [0x000001d2]
(0x0008,0x0005) CS Specific Character Set VR=<CS> VL=<0x000a> <ISO_IR 100>
...
% java -cp pixelmed.jar com.pixelmed.dicom.AttributeList debian_753809_badmetaelement.dcm
Error: Illegal duplicate tag in dataset - (0x0002,0x0003) - replacing previous occurence
[main] INFO com.pixelmed.dicom.AttributeList Dumping ...
(0x0002,0x0000) FileMetaInformationGroupLength VR=<UL> VL=<0x4> [0xd8]
(0x0002,0x0001) FileMetaInformationVersion VR=<OB> VL=<0x2> []
(0x0002,0x0002) MediaStorageSOPClassUID VR=<UI> VL=<0x1a> <1.2.840.10008.5.1.4.1.1.1>
(0x0002,0x0003) MediaStorageSOPInstanceUID VR=<UI> VL=<0x3a> <1.2.276.0.7230010.3.1.4.2831160242.3411.1400154379.583031>
(0x0002,0x0010) TransferSyntaxUID VR=<UI> VL=<0x12> <1.2.840.10008.1.2>
(0x0002,0x0012) ImplementationClassUID VR=<UI> VL=<0x1c> <1.2.276.0.7230010.3.0.3.6.0>
(0x0002,0x0013) ImplementationVersionName VR=<SH> VL=<0x10> <OFFIS_DCMTK_360 >
(0x0002,0x0016) SourceApplicationEntityTitle VR=<AE> VL=<0x8> <GNUMEDLH>
(0x0008,0x0000) VR=<UN> VL=<0x4> [B@12edcd21
(0x0008,0x0005) SpecificCharacterSet VR=<CS> VL=<0xa> <ISO_IR 100>
...
file, so the bug is in the source system, not the
recipient.
The error is caused by the (0002,0003) data element being
repeated:
- once within the meta information header (within the length
specified by group length (0002,0003))
- once at the beginning of the data set
which can be interpreted as being incorrect in various
ways:
- group 0002 data elements may not occur outside the meta
information header, as Mathieu points out
- data elements may not be repeated
- data elements must be in ascending numerical order
Since the meta information is encoded in explicit VR and
the data set in implicit VR, the two copies of (0002,0003)
are encoded slightly differently, but they do contain the
same value.
I mention this because it explains why toolkits behave
differently with this illegal file (as Mathieu and Jörg
have discussed):
- those that determine the end of the meta information
header based on the (mandatory) group length of group
0002 may switch transfer syntax from explicit to implicit
before the offending tag and read it, and then may or
may not complain about its presence being illegal
(duplicate or out of order), or may just silently
ignore it
- those that use the change of group number from 0002 to
something higher to detect the end of the meta header may
not read the offending implicit VR encoded extra out of
order group 0002 data element correctly if they try to
parse it as explicit VR, and get out of sync
The Implementation Version Name in the meta information header
says "OFFIS_DCMTK_360", but dcmtk doesn't make this kind
of error, as far as I know, so it would be good to know what
system actually encoded this bad DICOM file.
David
% andump debian_753809_badmetaelement.dcm
(0x0002,0x0000) UL File Meta Information Group Length VR=<UL> VL=<0x0004> [0x000000d8]
(0x0002,0x0001) OB File Meta Information Version VR=<OB> VL=<0x0002> [0x00,0x01]
(0x0002,0x0002) UI Media Storage SOP Class UID VR=<UI> VL=<0x001a> <1.2.840.10008.5.1.4.1.1.1>
(0x0002,0x0003) UI Media Storage SOP Instance UID VR=<UI> VL=<0x003a> <1.2.276.0.7230010.3.1.4.2831160242.3411.1400154379.583031>
(0x0002,0x0010) UI Transfer Syntax UID VR=<UI> VL=<0x0012> <1.2.840.10008.1.2>
(0x0002,0x0012) UI Implementation Class UID VR=<UI> VL=<0x001c> <1.2.276.0.7230010.3.0.3.6.0>
(0x0002,0x0013) SH Implementation Version Name VR=<SH> VL=<0x0010> <OFFIS_DCMTK_360 >
(0x0002,0x0016) AE Source Application Entity Title VR=<AE> VL=<0x0008> <GNUMEDLH>
(0x0002,0x0003) UI Media Storage SOP Instance UID VR=<UN> VL=<0x003a> [0x31,0x2e,0x32,0x2e,0x32,0x37,0x36,0x2e,0x30,0x2e,0x37,0x32,0x33,0x30,0x30,0x31,0x30,0x2e,0x33,0x2e,0x31,0x2e,0x34,0x2e,0x32,0x38,0x33,0x31,0x31,0x36,0x30,0x32,0x34,0x32,0x2e,0x33,0x34,0x31,0x31,0x2e,0x31,0x34,0x30,0x30,0x31,0x35,0x34,0x33,0x37,0x39,0x2e,0x35,0x38,0x33,0x30,0x33,0x31,0x00]
(0x0008,0x0000) UL Group Length VR=<UL> VL=<0x0004> [0x000001d2]
(0x0008,0x0005) CS Specific Character Set VR=<CS> VL=<0x000a> <ISO_IR 100>
...
% dcdump -ignoreoutofordertags debian_753809_badmetaelement.dcm
Warning - Tags out of order - trailing garbage, wrong transfer syntax, or not valid DICOM
(0x0002,0x0003) UI Media Storage SOP Instance UID Error - Tag read failed - Implicit VR encoding even though supposed to be explicit
Warning - Bad group length - Group 0x2 specified as 0xd8 actually 0x11a
Error - Dicom dataset read failed
(0x0002,0x0000) UL File Meta Information Group Length VR=<UL> VL=<0x0004> [0x000000d8]
(0x0002,0x0001) OB File Meta Information Version VR=<OB> VL=<0x0002> [0x00,0x01]
(0x0002,0x0002) UI Media Storage SOP Class UID VR=<UI> VL=<0x001a> <1.2.840.10008.5.1.4.1.1.1>
(0x0002,0x0003) UI Media Storage SOP Instance UID VR=<UI> VL=<0x003a> <1.2.276.0.7230010.3.1.4.2831160242.3411.1400154379.583031>
(0x0002,0x0003) UI Media Storage SOP Instance UID VR=<UI> VL=<0x003a> <1.2.276.0.7230010.3.1.4.2831160242.3411.1400154379.583031>
(0x0002,0x0010) UI Transfer Syntax UID VR=<UI> VL=<0x0012> <1.2.840.10008.1.2>
(0x0002,0x0012) UI Implementation Class UID VR=<UI> VL=<0x001c> <1.2.276.0.7230010.3.0.3.6.0>
(0x0002,0x0013) SH Implementation Version Name VR=<SH> VL=<0x0010> <OFFIS_DCMTK_360 >
(0x0002,0x0016) AE Source Application Entity Title VR=<AE> VL=<0x0008> <GNUMEDLH>
(0x0008,0x0000) UL Group Length VR=<UL> VL=<0x0004> [0x000001d2]
(0x0008,0x0005) CS Specific Character Set VR=<CS> VL=<0x000a> <ISO_IR 100>
...
% java -cp pixelmed.jar com.pixelmed.dicom.AttributeList debian_753809_badmetaelement.dcm
Error: Illegal duplicate tag in dataset - (0x0002,0x0003) - replacing previous occurence
[main] INFO com.pixelmed.dicom.AttributeList Dumping ...
(0x0002,0x0000) FileMetaInformationGroupLength VR=<UL> VL=<0x4> [0xd8]
(0x0002,0x0001) FileMetaInformationVersion VR=<OB> VL=<0x2> []
(0x0002,0x0002) MediaStorageSOPClassUID VR=<UI> VL=<0x1a> <1.2.840.10008.5.1.4.1.1.1>
(0x0002,0x0003) MediaStorageSOPInstanceUID VR=<UI> VL=<0x3a> <1.2.276.0.7230010.3.1.4.2831160242.3411.1400154379.583031>
(0x0002,0x0010) TransferSyntaxUID VR=<UI> VL=<0x12> <1.2.840.10008.1.2>
(0x0002,0x0012) ImplementationClassUID VR=<UI> VL=<0x1c> <1.2.276.0.7230010.3.0.3.6.0>
(0x0002,0x0013) ImplementationVersionName VR=<SH> VL=<0x10> <OFFIS_DCMTK_360 >
(0x0002,0x0016) SourceApplicationEntityTitle VR=<AE> VL=<0x8> <GNUMEDLH>
(0x0008,0x0000) VR=<UN> VL=<0x4> [B@12edcd21
(0x0008,0x0005) SpecificCharacterSet VR=<CS> VL=<0xa> <ISO_IR 100>
...
Marco Eichelberg
Feb 1, 2016, 3:32:48 AM2/1/16
to
> The Implementation Version Name in the meta information header
> says "OFFIS_DCMTK_360", but dcmtk doesn't make this kind
> of error, as far as I know, so it would be good to know what
> system actually encoded this bad DICOM file.
The presence of (0002,0016) Source Application Entity Title AE
> says "OFFIS_DCMTK_360", but dcmtk doesn't make this kind
> of error, as far as I know, so it would be good to know what
> system actually encoded this bad DICOM file.
in the metaheader indicates that DCMTK (or DCMTK based tool)
has received the dataset as an incoming C-STORE transaction
and written the result to file. I would think that the illegal
extra Media Storage SOP Instance UID was already present in
this incoming dataset - DCMTK never creates this on its own
in the main dataset.
The Source AE is "GNUMEDLH". Just guessing, but there is an
open source project named "GNUmed" (http://wiki.gnumed.de/bin/view/Gnumed)
which seems to have some DICOM funcationality.
Best regards,
Marco Eichelberg
0 new messages