[Insight-developers] DCMTK ImageIO Questions
Steve Pieper
pieper at ibility.net
Fri Sep 28 13:20:13 EDT 2012
Hi Kent -
Yes, I see the point of not using plugins as part of an ImageIO - it
would complicate things.
Let's get something that works and then do timings to figure out if
there is extraneous work being done that can be avoided by pre-caching
or other techniques.
Thanks,
Steve
On Wed, Sep 26, 2012 at 11:38 AM, Williams, Norman K
<norman-k-williams at uiowa.edu> wrote:
> I'm in a state of flux with this work, I'm trying to perfect DWIConvert to
> use the new DCMTK ImageIO. My testing now involves using DWIConvert on
> the whole corpus of DICOM DWI datasets we have for the Predict-HD project
> (http:://www.predict-hd.net) This is more specific to DWIConvert than
> DCMTK ImageIO in ITK, but it does raise my confidence level in the latter
> to run the former on a large corpus of DICOM datasets.
>
> I solved the problem that started this theread by not using DicomImage to
> render images, but rather use the 'InterData' DiPixel class to recover the
> pixel data.
>
> https://github.com/Chaircrusher/NewDicomToNrrdConverter
>
> When I finish the work on DWIConvert, I will be returning to work on the
> ITK DCMTKImageIO in ITK proper and push a new Gerrit patch.
>
> The fundamental problem with trying to use plug-ins with ImageIO classes
> is that it should not be an ad hoc addition to itk::DCMTKImageIO. It
> should be some sort of general mechanism that is part of itk::ImageIOBase.
>
> DCMTK is fairly smart about loading headers; you can constrain the size of
> data loaded on opening a DcmFileFormat so you can load a DICOM image
> without loading the pixel data. I'm not sure what real-world performance
> increase you would get by trying to pass around DcmDataSet pointers, and
> I'm not sure if the performance increase would justify the increase in
> software complexity.
>
> There's a lot to recommend about treating ITK ImageIO as a 'black box' --
> give it a filename and it gives back an image. It's already complicated
> by multi-file formats like DICOM -- you can't just pass in a DICOM
> directory and expect to get an image back, you have to detect that case
> and use ImageSeriesReader instead of ImageReader.
>
> --
> Kent Williams norman-k-williams at uiowa.edu
>
>
>
>
>
>
> On 9/21/12 1:21 PM, "Steve Pieper" <pieper at ibility.net> wrote:
>
>>Hi Kent -
>>
>>I can say that in the ctk code does display these images and they look
>>correct - internally DicomImage is converted to QImage (going through
>>a PPM/PGM workaround that I understand originally came from Jorg).
>>
>>https://github.com/commontk/CTK/blob/master/Libs/DICOM/Widgets/ctkDICOMDat
>>asetView.cpp#L265
>>
>>But maybe there's a better way to get to the raw data - I'm not sure.
>>
>>Regarding the 'pluggable' idea: is your code in github? Perhaps I
>>could add comments of places where I think we could generalize. I'd
>>like to try taking advantage of pre-cached data if possible to avoid
>>reloading all the headers (of course, if you need to load the pixel
>>data anyway it may not help to use the pre-cached headers).
>>
>>Thanks,
>>Steve
>>
>>
>>On Wed, Sep 19, 2012 at 2:27 PM, Williams, Norman K
>><norman-k-williams at uiowa.edu> wrote:
>>> No I'm not convinced I'm using DCMTK entirely correctly ;-)
>>>
>>> I've narrowed the problem down to this: DicomImage is a rendering
>>> interface, meaning that if left to its own devices, it will scale the
>>> image data according to whether or not it thinks the data is signed
>>>data.
>>> I've been told by J. Riesmeier that the change in voxel values has to do
>>> with the data data being 'potentially signed.' I've traced through the
>>> code and don't entirely follow the logic. Riesmeier is convinced that
>>> DCMTK is doing the right thing at least for the DicomImage rendering
>>> interface.
>>>
>>> I don't know how I could make the itk::ImageIO for DCMTK 'pluggable', or
>>> what data could be plugged in. Right now I have it doing an OK job of
>>> reading images, except for the weird pixel value shift I was talking
>>> about. In the code I've been working on the itk::DCMTKImageIO is used
>>>to
>>> read in the gradient magnitude image, and I use direct calls into DCMTK
>>>to
>>> recover the gradient vectors and B values.
>>>
>>>
>>> On 9/18/12 5:43 PM, "Steve Pieper" <pieper at ibility.net> wrote:
>>>
>>>
>>>>Hi Kent -
>>>>
>>>>I took a quick look at the data in question it looks like the GDCM
>>>>data range is consistent with the data. If you look at dcmdump output
>>>>for one of the files [1] you can see that the data is meant to be 16
>>>>bit 2's complement data, but with the smallest value of 0 and the
>>>>highest of 946. See [2] for a description of the fields. Other files
>>>>have higher values, so I can believe that 23819 is the max and 0 is
>>>>the min. Plus, when I load this in slicer it looks like valid dwi
>>>>data and the numbers are consistent with what I expect.
>>>>
>>>>Are you sure you are using DCMTK correctly? I wouldn't expect it to
>>>>incorrectly read this kind of data. In any case I think that unless
>>>>gdcm were obviously wrong, I would think that your new dcmtk-based
>>>>reader should give the same pixel results wherever possible.
>>>>
>>>>Regarding your question #2: for slicer purposes I'd prefer that ITK
>>>>not put dicom headers onto the ITK images. In slicer we associate a
>>>>list of instance UIDs with a volume so that you can find the instance
>>>>that corresponds to each slice. Then if the information is needed, an
>>>>algorithm can query the database for more information and/or the whole
>>>>header if needed (and only if needed). So if you do decide to put the
>>>>dicom header info into the metadata dictionary, please provide a way
>>>>to turn of the feature for efficiency.
>>>>
>>>>BTW, since slicer already has a database with pre-cached values for
>>>>many of the header fields (position, orientation, etc) it would be
>>>>great if your reader were somehow plugable so that we could avoid
>>>>reparsing all the files during the itkimageIO step. Let me know if
>>>>you want to discuss this - ideally we could have some kind of abstract
>>>>header query class and slicer could provide an implementation that
>>>>uses the database while native ITK would reparse the files during
>>>>load.
>>>>
>>>>Thanks,
>>>>Steve
>>>>
>>>>[1] the image pixel attributes of file E7695S4I1008.MR.new
>>>>
>>>>(0028,0002) US 1 # 2, 1
>>>>SamplesPerPixel
>>>>(0028,0004) CS [MONOCHROME2] # 12, 1
>>>>PhotometricInterpretation
>>>>(0028,0010) US 256 # 2, 1 Rows
>>>>(0028,0011) US 256 # 2, 1 Columns
>>>>(0028,0030) DS [1\1] # 4, 2
>>>>PixelSpacing
>>>>(0028,0100) US 16 # 2, 1
>>>>BitsAllocated
>>>>(0028,0101) US 16 # 2, 1
>>>>BitsStored
>>>>(0028,0102) US 15 # 2, 1 HighBit
>>>>(0028,0103) US 1 # 2, 1
>>>>PixelRepresentation
>>>>(0028,0106) SS 0 # 2, 1
>>>>SmallestImagePixelValue
>>>>(0028,0107) SS 946 # 2, 1
>>>>LargestImagePixelValue
>>>>(0028,1050) DS [473] # 4, 1
>>>>WindowCenter
>>>>(0028,1051) DS [946] # 4, 1
>>>>WindowWidth
>>>>
>>>>
>>>>[2] http://dicomlookup.com/lookup.asp?sw=Ttable&q=C.7-11
>>>>
>>>>
>>>>On Fri, Sep 14, 2012 at 5:06 PM, Williams, Norman K
>>>><norman-k-williams at uiowa.edu> wrote:
>>>>> I started testing the itk DCMTKImageIO for reading DICOM images this
>>>>>week,
>>>>> by using it in DWIConvert, which is my re-write of the Slicer
>>>>> DicomToNrrdConverter program. It works fine, and passes all the
>>>>>DWIConvert
>>>>> regression tests except for one.
>>>>>
>>>>> That one test starts from a DICOM data set from MIDAS -- the
>>>>>GeSignaHDx
>>>>> data set here http://midas.kitware.com/item/view/542
>>>>>
>>>>> The issue is scaling of the Pixel data. Due to some obscure decisions
>>>>> about scaling data, GDCM produces pixels in the range 0..23819, DCMTK
>>>>> produces voxels in the range -32768..-8949 as reported by Slicer4. By
>>>>> stepping through the DCMTK library, it looks as though it applies this
>>>>> data shift on the basis of the image modality.
>>>>>
>>>>> The question is this: does GDCM does it right -- not shifting pixel
>>>>> values, or does DCMTZK do it right?
>>>>>
>>>>> Question #2:
>>>>>
>>>>> There was some discussion on the mailing list some months back about
>>>>> exposing the DICOM tags by copying them out to the MetaDataDictionary
>>>>>when
>>>>> reading a DICOM series. Right now nothing is done -- only the Image
>>>>>data,
>>>>> directions, origin, and spacing are recovered from the DICOM series on
>>>>> reading.
>>>>>
>>>>> What should happen? There was some discussion of exposing an
>>>>>interface
>>>>> for extracting Dicom metadata in a consistent manner across both
>>>>>readers,
>>>>> but I don't remember anyone deciding anything or beginning a design.
>>>>> --
>>>>> Kent Williams norman-k-williams at uiowa.edu
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> ________________________________
>>>>> Notice: This UI Health Care e-mail (including attachments) is covered
>>>>>by the Electronic Communications Privacy Act, 18 U.S.C. 2510-2521, is
>>>>>confidential and may be legally privileged. If you are not the
>>>>>intended
>>>>>recipient, you are hereby notified that any retention, dissemination,
>>>>>distribution, or copying of this communication is strictly prohibited.
>>>>>Please reply to the sender that you have received the message in error,
>>>>>then delete it. Thank you.
>>>>> ________________________________
>>>>> _______________________________________________
>>>>> Powered by www.kitware.com
>>>>>
>>>>> Visit other Kitware open-source projects at
>>>>> http://www.kitware.com/opensource/opensource.html
>>>>>
>>>>> Kitware offers ITK Training Courses, for more information visit:
>>>>> http://kitware.com/products/protraining.php
>>>>>
>>>>> Please keep messages on-topic and check the ITK FAQ at:
>>>>> http://www.itk.org/Wiki/ITK_FAQ
>>>>>
>>>>> Follow this link to subscribe/unsubscribe:
>>>>> http://www.itk.org/mailman/listinfo/insight-developers
>>>
>>>
>>>
>>> ________________________________
>>> Notice: This UI Health Care e-mail (including attachments) is covered
>>>by the Electronic Communications Privacy Act, 18 U.S.C. 2510-2521, is
>>>confidential and may be legally privileged. If you are not the intended
>>>recipient, you are hereby notified that any retention, dissemination,
>>>distribution, or copying of this communication is strictly prohibited.
>>>Please reply to the sender that you have received the message in error,
>>>then delete it. Thank you.
>>> ________________________________
>
>
>
> ________________________________
> Notice: This UI Health Care e-mail (including attachments) is covered by the Electronic Communications Privacy Act, 18 U.S.C. 2510-2521, is confidential and may be legally privileged. If you are not the intended recipient, you are hereby notified that any retention, dissemination, distribution, or copying of this communication is strictly prohibited. Please reply to the sender that you have received the message in error, then delete it. Thank you.
> ________________________________
More information about the Insight-developers
mailing list