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 <[email protected]> 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 [email protected] > > > > > > > ________________________________ > 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 _______________________________________________ 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
