Reading Dicom sequence data with SimpleITK

When reading mammography images there are several Dicom tags relevant to be able to display the image correctly as described in the dicom standard. These are stored in the VOILUTFunction and VOILUTSequence. The first is a low-level tag, and can be easily read, however, the second does not.

For instance, dcmdump gives this for my file:

(base) ➜  pngs dcmdump mammogram.dcm | grep -i lut
(0028,1055) LO [linear LUT]                             #  10, 1 WindowCenterWidthExplanation
(0028,3010) SQ (Sequence with explicit length #=4)      # 32974, 1 VOILUTSequence
    (0028,3002) US 4096\0\12                                #   6, 3 LUTDescriptor
    (0028,3003) LO [Flavor3_35_280]                         #  14, 1 LUTExplanation
    (0028,3006) US 0\6\6\6\6\6\6\6\6\7\7\7\7\7\7\7\7\7\7\7\7\7\7\7\7\7\7\7\7\7\7\7\7\7... # 8192,4096 LUTData
    (0028,3002) US 4096\0\12                                #   6, 3 LUTDescriptor
    (0028,3003) LO [Flavor3_37_250]                         #  14, 1 LUTExplanation
    (0028,3006) US 0\10\10\10\10\10\10\10\10\10\10\10\10\10\10\10\11\11\11\11\11\11\11... # 8192,4096 LUTData
    (0028,3002) US 4096\0\12                                #   6, 3 LUTDescriptor
    (0028,3003) LO [Flavor3_37_230]                         #  14, 1 LUTExplanation
    (0028,3006) US 0\11\11\11\11\11\11\11\11\11\12\12\12\12\12\12\12\12\12\12\12\12\12... # 8192,4096 LUTData
    (0028,3002) US 4096\0\12                                #   6, 3 LUTDescriptor
    (0028,3003) LO [Flavor3_LUT1]                           #  12, 1 LUTExplanation
    (0028,3006) US 0\17\17\17\17\17\18\18\18\18\18\18\18\18\18\18\18\18\18\18\18\18\19... # 8192,4096 LUTData

While with SimpleITK I get:

sitk_image.GetMetaData('0028|3010')

RuntimeError: Exception thrown in SimpleITK Image_GetMetaData: /Users/runner/runners/2.160.0/work/1/sitk-build/ITK/Modules/Core/Common/src/itkMetaDataDictionary.cxx:88:
itk::ERROR: Key '0028|3010' does not exist 

Is there a way of doing this currently with SimpleITK or would it be better to use pydicom for this? It would be a little bit unfortunate, as this would mean I need to read the header twice (and have another dependency).

Seem that itkMetaDataDictionary class doesn’t know that tag, so an overcome will be to read that tag before SimpleITK with other lib/object, either to delete that tag, or, modify it, and consider later as you needs.

If you app allow to read the data with VTK, I can help you.

1 Like

Hello @jonasteuwen,

Generally speaking SimpleITK will read all the tags and they should be accessible.
How are you reading the images, ImageFileReader or ImageSeriesReader? Are all other tags loaded (GetMetaDataKeys)?

Possibly if you could share the code used for reading and the image we could better help you (preferably both, but just the code would help in understanding what went wrong).

Hi @zivy

I am reading the image as follows (mammograms are single dicom files): img = sitk.ReadImage(fn). Other DICOM tags are properly read, and are in GetMetaDataKeys, however '0028|3010' is not. For instance, the modality tag img.GetMetaData('0008|0060') properly returns MG.

For instance this piece of code (with ImageFileReader) also does not output the sequence tags:

reader = sitk.ImageFileReader()

reader.SetFileName(image_fn)
reader.LoadPrivateTagsOn();

reader.ReadImageInformation();

for k in reader.GetMetaDataKeys():
    v = reader.GetMetaData(k)
    print(k, v)

Best,
Jonas

Hi @jonasteuwen,

Code looks good, so it may be an issue with SimpleITK/ITK, possibly related to this question. Underneath the SimpleITK hood we are using GDCM, which does have a Python binding (Examples here).

If you can share the data we may be able to debug this or identify if we have missing functionality.

2 Likes

Dear @zivy, in that case I think it is a missing feature. I will see if I can find data which can be shared with such sequence information. Likely the same issue will arise with a CT scan with an associated RTSTRUCT.

Best,
Jonas.

Hello,

What version of SimpleITK are you using? It may be worth trying SimpleITK 2.0 rc 1, as GDCM version has been updated which might address the issue.

Hello Bradley,

I can confirm the problem still persists, I am only able to access the top-level keys tags, and no childs (which definitely exist if I check the output of dcmdump). I am not very familiar with the ITK source code, but if you could point me to the relevant part of the Metadata reading of DICOM images, I might be able to find the reason.

Best,
Jonas

Hello,

SimpleITK used GDCM for reading the DICOM files and metadata. You can find the library on GitHub here:

The ITK class which interfaces with GDCM is here:

@mathieu.malaterre is the maintainer of GDCM. I believe there should be some GDCM tools to inspect you file to verify if GDCM is doing the right thing, of if there is a problem with ITKGDCMImageIO.

ITKGDCMImageIO doesn’t read sequences for metadata dictionary, s. here and here. It was never supported and already mentioned several times, e.g. the topic.

2 Likes

Hi,

Thanks for figuring out where this is located. Is this a intended feature for ITK (I suppose that the sequences load slower) or would it be possible to allow to load this, e.g. with LoadDicomSequences() just as with LoadPrivateTags()? It seems more important than the private tags - imagine you want to match an RTSTRUCT with its CT scan. The ReferenceFrameUID is part of a sequence.

The DCMTK backend seems to support sequences.

1 Like

Yes, i also think that sequences are absolutely important and that without sequences it doesn’t make sense to rely on metadata dictionary for DICOM attributes at all. Currently it is better to take pydicom (or low level GDCM / DCMTK for C++), if there is a requirement to access attributes.

P.S. Also, not sure it will be a good idea to add support for whole data set in meta data dictionary, but it is another, longer story.

It would at least be an idea to allow the reading of the whole dictionary (just as it allows reading of the private tags), or expose a method to lookup the tag, or disable it so we can implement more efficient means using DCMTK.