[Insight-developers] DCMTK ImageIO Questions

[Steve Pieper]

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