[Insight-developers] DCMTK ImageIO Questions
Williams, Norman K
norman-k-williams at uiowa.edu
Wed Sep 19 14:27:37 EDT 2012
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.
________________________________
More information about the Insight-developers
mailing list