Invalid DICOMDIR?
Moderator: Moderator Team
-
- Posts: 15
- Joined: Mon, 2009-08-17, 21:40
- Location: California
Invalid DICOMDIR?
I have received sample files from a medical device manufacturer that give the UID UltrasoundMultiframeImageStorage for the MediaStorageSOPClassUID (0002,0002) tag instead of the expected MediaStorageDirectoryStorage. Is this legal? Is there some legitimate way to use such DICOMDIRs beyond giving an error message? Is there an option in dcmtk for ignoring the MediaStorageSOPClassUID field??
-
- DCMTK Developer
- Posts: 2506
- Joined: Tue, 2011-05-03, 14:38
- Location: Oldenburg, Germany
- Contact:
Re: Invalid DICOMDIR?
No, of course not. Are you sure that the creator of this SOP instance really wanted to encode a DICOMDIR?Is this legal?
-
- Posts: 15
- Joined: Mon, 2009-08-17, 21:40
- Location: California
Re: Invalid DICOMDIR?
Looks like it to me:
# Dicom-File-Format
# Dicom-Meta-Information-Header
# Used TransferSyntax: LittleEndianExplicit
(0002,0000) UL 216 # 4, 1 MetaElementGroupLength
(0002,0001) OB 00\01 # 2, 1 FileMetaInformationVersion
(0002,0002) UI =UltrasoundMultiframeImageStorage # 28, 1 MediaStorageSOPClassUID
(0002,0003) UI [2.16.840.x.xxxxxx.518.1276.634732793312656.32.149.69.56.134.12] # 62, 1 MediaStorageSOPInstanceUID
(0002,0010) UI =LittleEndianExplicit # 20, 1 TransferSyntaxUID
(0002,0012) UI [2.16.840.x.xxxxxx] # 18, 1 ImplementationClassUID
(0002,0013) SH [xxx:2.0.3] # 10, 1 ImplementationVersionName
(0002,0016) AE [VOL_MEDIA_STORE] # 16, 1 SourceApplicationEntityTitle
# Dicom-Data-Set
# Used TransferSyntax: LittleEndianExplicit
(0004,1130) CS [Unspecified28_20120522] # 22, 1 FileSetID
(0004,1200) up 436 # 4, 1 OffsetOfTheFirstDirectoryRecordOfTheRootDirectoryEntity
(0004,1202) up 436 # 4, 1 OffsetOfTheLastDirectoryRecordOfTheRootDirectoryEntity
(0004,1212) US 0 # 2, 1 FileSetConsistencyFlag
(0004,1220) SQ (Sequence with undefined length #=5) # u/l, 1 DirectoryRecordSequence
(fffe,e000) na "Directory Record" PATIENT #=8 # u/l, 1 Item
# offset=$436
(0004,1400) up 0 # 4, 1 OffsetOfTheNextDirectoryRecord
(0004,1410) US 65535 # 2, 1 RecordInUseFlag
(0004,1420) up 570 # 4, 1 OffsetOfReferencedLowerLevelDirectoryEntity
(0004,1430) CS [PATIENT] # 8, 1 DirectoryRecordType
.
.
.
[ Note that I've anonymized the guilty party.]
# Dicom-File-Format
# Dicom-Meta-Information-Header
# Used TransferSyntax: LittleEndianExplicit
(0002,0000) UL 216 # 4, 1 MetaElementGroupLength
(0002,0001) OB 00\01 # 2, 1 FileMetaInformationVersion
(0002,0002) UI =UltrasoundMultiframeImageStorage # 28, 1 MediaStorageSOPClassUID
(0002,0003) UI [2.16.840.x.xxxxxx.518.1276.634732793312656.32.149.69.56.134.12] # 62, 1 MediaStorageSOPInstanceUID
(0002,0010) UI =LittleEndianExplicit # 20, 1 TransferSyntaxUID
(0002,0012) UI [2.16.840.x.xxxxxx] # 18, 1 ImplementationClassUID
(0002,0013) SH [xxx:2.0.3] # 10, 1 ImplementationVersionName
(0002,0016) AE [VOL_MEDIA_STORE] # 16, 1 SourceApplicationEntityTitle
# Dicom-Data-Set
# Used TransferSyntax: LittleEndianExplicit
(0004,1130) CS [Unspecified28_20120522] # 22, 1 FileSetID
(0004,1200) up 436 # 4, 1 OffsetOfTheFirstDirectoryRecordOfTheRootDirectoryEntity
(0004,1202) up 436 # 4, 1 OffsetOfTheLastDirectoryRecordOfTheRootDirectoryEntity
(0004,1212) US 0 # 2, 1 FileSetConsistencyFlag
(0004,1220) SQ (Sequence with undefined length #=5) # u/l, 1 DirectoryRecordSequence
(fffe,e000) na "Directory Record" PATIENT #=8 # u/l, 1 Item
# offset=$436
(0004,1400) up 0 # 4, 1 OffsetOfTheNextDirectoryRecord
(0004,1410) US 65535 # 2, 1 RecordInUseFlag
(0004,1420) up 570 # 4, 1 OffsetOfReferencedLowerLevelDirectoryEntity
(0004,1430) CS [PATIENT] # 8, 1 DirectoryRecordType
.
.
.
[ Note that I've anonymized the guilty party.]
-
- DCMTK Developer
- Posts: 2506
- Joined: Tue, 2011-05-03, 14:38
- Location: Oldenburg, Germany
- Contact:
Re: Invalid DICOMDIR?
Ok, you are correct. This is really a serious bug in the software of that particular device (or whoever created the file-meta information header).
As a workaround, you could check in your DCMTK-based software whether the DirectoryRecordSequence and other DICOMDIR-specific attributes are present and replace the MediaStorageSOPClassUID accordingly.
As a workaround, you could check in your DCMTK-based software whether the DirectoryRecordSequence and other DICOMDIR-specific attributes are present and replace the MediaStorageSOPClassUID accordingly.
-
- Posts: 15
- Joined: Mon, 2009-08-17, 21:40
- Location: California
Re: Invalid DICOMDIR?
Thanks. Sounds like that should work.
-
- Posts: 15
- Joined: Mon, 2009-08-17, 21:40
- Location: California
Re: Invalid DICOMDIR?
After several years, I am afraid I am back in Invalid DICOMDIR land.
We have received sample files from a set of IVUS DICOM files saved from a BSC iLab system pushed to a PACS system then retrieved and presented to our software (from a very important customer).
Our software is rejecting the DICOMDIR, and confusing the user.
There are two problems we see immediately.
When we run dcmdump.exe, at the top of the output it says "DcmMetaInfo: Group Length of MetaInformation Header has incorrect value." We have reviewed the definition of the (0002,0000) tag, and have struggled to understand the values that we see in other DICOM files, but this is the first case where we've seen this specific error from dcmdump.exe.
The path references in the DICOMDIR (for example
# offset=$918 refFileID="IMAGES\IM00001")
do not match the organization of the tree retrieved from the PACS. Plus, if I recreate the IMAGES folder and move IM00001 into it, our software still fails to find the file via the DICOMDIR (although this may be to the Group Length error ). It is also true that this path is not one that we have ever seen from Boston Scientific IVUS devices, which would typically have reference paths such <date>\CASE1\RUN1\<filename>.
I greatly appreciate the help you have given to the DICOM community over the past decades, and hope you help yet again.
We have received sample files from a set of IVUS DICOM files saved from a BSC iLab system pushed to a PACS system then retrieved and presented to our software (from a very important customer).
Our software is rejecting the DICOMDIR, and confusing the user.
There are two problems we see immediately.
When we run dcmdump.exe, at the top of the output it says "DcmMetaInfo: Group Length of MetaInformation Header has incorrect value." We have reviewed the definition of the (0002,0000) tag, and have struggled to understand the values that we see in other DICOM files, but this is the first case where we've seen this specific error from dcmdump.exe.
The path references in the DICOMDIR (for example
# offset=$918 refFileID="IMAGES\IM00001")
do not match the organization of the tree retrieved from the PACS. Plus, if I recreate the IMAGES folder and move IM00001 into it, our software still fails to find the file via the DICOMDIR (although this may be to the Group Length error ). It is also true that this path is not one that we have ever seen from Boston Scientific IVUS devices, which would typically have reference paths such <date>\CASE1\RUN1\<filename>.
I greatly appreciate the help you have given to the DICOM community over the past decades, and hope you help yet again.
-
- DCMTK Developer
- Posts: 2506
- Joined: Tue, 2011-05-03, 14:38
- Location: Oldenburg, Germany
- Contact:
Re: Invalid DICOMDIR?
In order to understand the background of your question: between "retrieved" and "presented" a DICOM storage medium is created, so your software is a File-set Reader (FSR) and not a Storage SCP?We have received sample files from a set of IVUS DICOM files saved from a BSC iLab system pushed to a PACS system then retrieved and presented to our software [...]
Last edited by J. Riesmeier on Tue, 2022-02-22, 12:24, edited 1 time in total.
-
- OFFIS DICOM Team
- Posts: 1445
- Joined: Tue, 2004-11-02, 17:22
- Location: Oldenburg, Germany
- Contact:
Re: Invalid DICOMDIR?
With regard to the metaheader group length (0002,000): this specifies the point in the file where the transfer syntax changes from the one used for the meta-header to the one used for the main dataset, and as such is a very important piece of information in the DICOM fileformat. Getting that wrong is a certain way of ensuring that nobody can reliably read your file. In DCMTK, several tools (including dcmdump and dcmconv) have a command line option
--ignore-meta-length
that causes the parser to ignore the value of that element and to use an "educated guess" instead. You might want to give that a try. However, if the offset values in the DICOMDIR are also wrong, then the DICOMDIR is simply unusable.-
- Posts: 15
- Joined: Mon, 2009-08-17, 21:40
- Location: California
Re: Invalid DICOMDIR?
I believe that we are seeing the problem when we are acting as a File-set Reader.
Thank you for the explanation of the metaheader group length (0002,000). Pursuing your suggetion now.
Thank you for the explanation of the metaheader group length (0002,000). Pursuing your suggetion now.
-
- Posts: 15
- Joined: Mon, 2009-08-17, 21:40
- Location: California
Re: Invalid DICOMDIR?
Our "forensic analysis" leads us to believe the following.
The data set was produced by a Boston Scientific iLab device and was sent to the hospital PACS which was then queried to download the corresponding file set that we are investigating.
At some point the original DICOMDIR was replaced (by one generated by the PACS, presumably).
The received DICOMDIR has (at least) two problems.
First, the value of tag (0002, 0000) is incorrect, which error condition our software is not handling gracefully.
Second, neither the directory structure of the original file set nor the directory structure downloaded from the PACS is reflected correctly in the delivered structure.
Each file in the directory suffers from the same issue
In the delivered DICOMDIR:
(fffe,e000) na "Directory Record" IMAGE #=14 # 294, 1 Item
# offset=$918 refFileID="IMAGES\IM00001"
In most cases we have dealt with over the years, the BSC provided directory organization would correspond to a path something like
refFileID="???\CASE?\RUN?\IMG00001"
and to be appropriate to the structure actually downloaded onto the users' PC, it would be
refFileID="IMG00001"
Our current thinking is that all of these issues should be addressed to the IT department at the hospital and the PACS IT group.
We thank OFFIS for your always clear and rapid help!
The data set was produced by a Boston Scientific iLab device and was sent to the hospital PACS which was then queried to download the corresponding file set that we are investigating.
At some point the original DICOMDIR was replaced (by one generated by the PACS, presumably).
The received DICOMDIR has (at least) two problems.
First, the value of tag (0002, 0000) is incorrect, which error condition our software is not handling gracefully.
Second, neither the directory structure of the original file set nor the directory structure downloaded from the PACS is reflected correctly in the delivered structure.
Each file in the directory suffers from the same issue
In the delivered DICOMDIR:
(fffe,e000) na "Directory Record" IMAGE #=14 # 294, 1 Item
# offset=$918 refFileID="IMAGES\IM00001"
In most cases we have dealt with over the years, the BSC provided directory organization would correspond to a path something like
refFileID="???\CASE?\RUN?\IMG00001"
and to be appropriate to the structure actually downloaded onto the users' PC, it would be
refFileID="IMG00001"
Our current thinking is that all of these issues should be addressed to the IT department at the hospital and the PACS IT group.
We thank OFFIS for your always clear and rapid help!
Who is online
Users browsing this forum: Bing [Bot] and 1 guest