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 <[email protected]> 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 [email protected] > > > > > > > On 9/21/12 1:21 PM, "Steve Pieper" <[email protected]> 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 >><[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. >>> ________________________________ > > > > ________________________________ > 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
