Invalid DICOMDIR?

All other questions regarding DCMTK

Moderator: Moderator Team

Post Reply
Message
Author
Rich in Soquel
Posts: 15
Joined: Mon, 2009-08-17, 21:40
Location: California

Invalid DICOMDIR?

#1 Post by Rich in Soquel »

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??

J. Riesmeier
DCMTK Developer
Posts: 2501
Joined: Tue, 2011-05-03, 14:38
Location: Oldenburg, Germany
Contact:

Re: Invalid DICOMDIR?

#2 Post by J. Riesmeier »

Is this legal?
No, of course not. Are you sure that the creator of this SOP instance really wanted to encode a DICOMDIR?

Rich in Soquel
Posts: 15
Joined: Mon, 2009-08-17, 21:40
Location: California

Re: Invalid DICOMDIR?

#3 Post by Rich in Soquel »

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.]

J. Riesmeier
DCMTK Developer
Posts: 2501
Joined: Tue, 2011-05-03, 14:38
Location: Oldenburg, Germany
Contact:

Re: Invalid DICOMDIR?

#4 Post by J. Riesmeier »

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.

Rich in Soquel
Posts: 15
Joined: Mon, 2009-08-17, 21:40
Location: California

Re: Invalid DICOMDIR?

#5 Post by Rich in Soquel »

Thanks. Sounds like that should work.

Rich in Soquel
Posts: 15
Joined: Mon, 2009-08-17, 21:40
Location: California

Re: Invalid DICOMDIR?

#6 Post by Rich in Soquel »

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.

J. Riesmeier
DCMTK Developer
Posts: 2501
Joined: Tue, 2011-05-03, 14:38
Location: Oldenburg, Germany
Contact:

Re: Invalid DICOMDIR?

#7 Post by J. Riesmeier »

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 [...]
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?
Last edited by J. Riesmeier on Tue, 2022-02-22, 12:24, edited 1 time in total.

Marco Eichelberg
OFFIS DICOM Team
OFFIS DICOM Team
Posts: 1437
Joined: Tue, 2004-11-02, 17:22
Location: Oldenburg, Germany
Contact:

Re: Invalid DICOMDIR?

#8 Post by Marco Eichelberg »

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.

Rich in Soquel
Posts: 15
Joined: Mon, 2009-08-17, 21:40
Location: California

Re: Invalid DICOMDIR?

#9 Post by Rich in Soquel »

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.

Rich in Soquel
Posts: 15
Joined: Mon, 2009-08-17, 21:40
Location: California

Re: Invalid DICOMDIR?

#10 Post by Rich in Soquel »

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!

Post Reply

Who is online

Users browsing this forum: Ahrefs [Bot], Baidu [Spider], Google [Bot] and 1 guest