Read FileSetID information from DICOMDIR

[chrrossmanith]

Hi,

so far I've successfully read the tree structure of a DICOMDIR file (patients, studies, series, images) using DcmDicomDir and DcmDirectoryRecord. Now I'd like to read the FileSetID information from a DICOMDIR file. If I use search(DCM_FileSetID, dcm_stack) on the root record it returns with an error condition and an empty stack though the information is present in the file.

So my question is: How do I access elements fo group 0002 and 0004 of a DICOMDIR file using dcmtk?

Thank you for any hint,
Christina Roßmanith

[Jörg Riesmeier]

Since the File-set ID is part of the File-set Identification Module and not of the Directory Information Module you should search on the main dataset and not on the root directory record. Btw, I would suggest to use findAndGetOFString() instead of search() and getOFString() ...

[chrrossmanith]

That means I would read DICOMDIR twice:

1) Using DcmDirectoryRecord to get the tree structure
2) Using DcmDataset to get additional information from the FileSetID Module

I'm quite new to dcmtk. My first attempt was to use search() and getOFString(), now I'm starting to optimize

Thank you!

[Jörg Riesmeier]

I'm quite new to dcmtk. My first attempt was to use search() and getOFString(), now I'm starting to optimize

Maybe, you should first have a look at these example.

[chrrossmanith]

If I access DICOMDIR with DcmFileFormat.loadFile() I get a lot of error or warning messages:

DcmItem: Element (0000,0000) found twice in one dataset/item, ignoring second entry
< repeated 17 times>
DcmItem: Dataset not in ascending tag order, at element (0004,00ae)
DcmItem: Length of attribute (2d5c,3031) is odd
DcmElement: Unknown Tag & Data(2d5c,3031) larger (909192755) that remaining bytes in file
DcmItem: Dataset not in ascending tag order, at element (2d5c,3031)

Is there a way to switch loadFile() to a non verbose mode? At least I can read the FileSetID now. Or are the above messages a hint to access DICOMDIR in a different way?

[tclune]

I've been working on something related to this topic, and the surprise to me was the following. The CD Volume Identifier must be the same as the File-set ID, and if there is no File-set ID, the Volume Identifier must be 15 space characters (3.12 annex F F.1.1). As near as I have been able to determine, there is no comparable requirement for DVDs.

This is only vaguely related to the OP, but it caught me off guard, so I wanted to make sure first that it is correct, and second that other implementors are aware of it. FWIW

[Jörg Riesmeier]

Or are the above messages a hint to access DICOMDIR in a different way?

No, these message are usually a hint that the file is corrupted ...

[chrrossmanith]

I've checked the dicomdir file using dvtk (dicom.dvtk.org) and it gave me no errors or warnings. It was created by dcm4chee.

A corrupt file would be the only explanation for the messages I get during reading the file?

[Jörg Riesmeier]

It would also be possible that you are using the wrong values for parameter "readXfer" and "readMode". The defaults should do.

We could also check your DICOMDIR. If it does not contain any patient-related information, just send the file to dicom/at/offis/dot/de.

[chrrossmanith]

It took me some time to anonymize the dicomdir file (usign gdcm). I've mailed the anonymized file just a moment ago. Thank you for offering to check the file!

Christina Rossmanith

[Marco Eichelberg]

The file you sent shows all kinds of errors, but not the errors you initially reported in your post. This is most probably due to the anonymization tool that you used - if the tool can read the file, then most low-level errors will be gone in the output. Also, it is impossible to say which errors in the file you have submitted were caused by the anonymization tool and which were there in the first place. Especially for DICOMDIRs, the only reliable way of anonymizing the file while retaining the underlying structure is to only replace patient names, birth dates etc. in the binary file using a Hex editor.

That said, the file you submitted shows the following errors:

• Values for various required fields such as Patient ID, Study Instance UID, Series Instance UID are missing.
• All the offset values that create the hierarchical structure of the DICOMDIR are incorrect.

[nmoraes]

Hello,

I'm having a similar problem, I'm trying to load a dicom file that I have generated with dcmtk libraries.

I get this warnings and error:

W: DcmItem: Element (0000,0000) found twice in one dataset/item, ignoring second entry
W: DcmItem: Element (0000,0000) found twice in one dataset/item, ignoring second entry
W: DcmItem: Element (0000,0000) found twice in one dataset/item, ignoring second entry
W: DcmItem: Element (0000,0000) found twice in one dataset/item, ignoring second entry
W: DcmItem: Element (0000,0000) found twice in one dataset/item, ignoring second entry
W: DcmItem: Element (0000,0000) found twice in one dataset/item, ignoring second entry
W: DcmItem: Element (0000,0000) found twice in one dataset/item, ignoring second entry
W: DcmItem: Element (0000,0000) found twice in one dataset/item, ignoring second entry
W: DcmItem: Element (0000,0000) found twice in one dataset/item, ignoring second entry
W: DcmItem: Element (0000,0000) found twice in one dataset/item, ignoring second entry
W: DcmItem: Element (0000,0000) found twice in one dataset/item, ignoring second entry
W: DcmItem: Element (0000,0000) found twice in one dataset/item, ignoring second entry
W: DcmItem: Element (0000,0000) found twice in one dataset/item, ignoring second entry
W: DcmItem: Element (0000,0000) found twice in one dataset/item, ignoring second entry
W: DcmItem: Element (0000,0000) found twice in one dataset/item, ignoring second entry
W: DcmItem: Dataset not in ascending tag order, at element (0004,00ca)
W: DcmItem: Length of element (fee3,fe6e) is odd
E: DcmElement: Unknown Tag & Data (fee3,fe6e) larger (22085567) than remaining bytes in file


I can open the same dicom file with other dicom tools and viewers. Do you know what I'm doing wrong?


Thanks

[Michael Onken]

Hi,

the file seems to contain invalid padding in the end, i.e. it is filled up with 0 at the very end. Try to run dcmdump on it. Probably it works fine until you encounter the 0000 tag errors, right?

Then try dcmdump with option " --stop-after-elem PixelData" and see whether parsing is fine. You then can convert the file with "dcmconv --stop-after-elem PixelData yourfile.dcm repairedfile.dcm" in order to repair it and save it to repairedfile.dcm. Of course you can also set these switches using the library, if you program yourself.

Note that any tags beyond PixelData will be missing in the repaired file, however, in 99% of the cases there are actually no tags beyond PixelData.

Best,
Michael

[nmoraes]

Hello Michael,

Thank you for your quick answer,

I don't use pixel data, my dicom file is a dicom waveform file. Running dcmdump I get all the tags from dicom file without errors.

Maybe I don't load the file correctly? I use the following code:

Code: Select all

	status = fileformat.loadFile("test.dcm", EXS_LittleEndianExplicit, EGL_noChange,  DCM_MaxReadLength, ERM_autoDetect);

[Michael Onken]

Hi,

dcmdump works, and your loadFile() fails? That's weird. You can try loadFile() with the filename and no other parameters, should be no problem. So does loadFile() return an error in your variable "status" (anything different than the value EC_Normal) or does it state it is ok?

If you like you can send the file for investigation to dicom at offis dot de.

Best,
Michael