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/ctkDICOMDatasetView.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 <[email protected]> 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" <[email protected]> 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 >><[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 > > > > ________________________________ > 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
