[Insight-developers] Dicom

[Miller, James V (Research)]

(Okay, I'm apparently not allowed to vote but here is some more input :)

I may be able to convince one of our projects here to release a DICOM "parser".
Basically, the parser understands the "syntax" of DICOM so it knows how to find
the tag/element pairs, knows how to determine whether the tag has an explicit or 
implicit length, know hows to swap bytes, and knows how to extract the data 
associated with a tag.  This is a fairly low level interface.  A user can then
register a callback for the tag/element pairs that they are interested in. For
instance, a FileIO reader could register that they want to know the pixel size, 
image dimensions, pixel offset and raw data. Or a reader may register that it 
wants to read some proprietary fields and the parser will call their callback
when it sees the proprietary fields. The callback mechanism is similar to the
ITK's observers.

The author, Matt Turek, was able to put together a little executable using this
library in about an hour that would run through a directory and list all the
series in the directory, what files were in each series, and what slice numbers
corresponded to what files.  It ran through a directory in about a second.

I haven't looked at ITK's current DICOM parser to know whether it has this level
of extensibility.  If this library would make it easier for ITK to provide  
(extensible) support for reading DICOM images, I'll press to see if we can release
this library. I'm thinking it may allow us to support the "basics" of reading
DICOM series and as people need to get more information out of their DICOM images
they can subclass our DICOM reader and register a few more callbacks.

Jim



> -----Original Message-----
> From: Stephen R. Aylward [mailto:aylward@unc.edu]
> Sent: Tuesday, September 17, 2002 1:58 AM
> To: Insight-Developers (E-mail)
> Subject: [Insight-developers] Dicom
> 
> 
> 
> Hi,
> 
> The more I think about it, perhaps we should consider including a 3rd 
> party library for DICOM into ITK or possibly including more 
> of the DICOM 
> stuff (grey scale standardization, intensity windowing, offsets, 
> overlays, etc.) in our implementation.  I hadn't planned on doing 
> either, but there is definite appeal to these other options.   Either 
> option will require significant work and maintenance, but DICOM is a 
> standard that we should support - perhaps better than we already do.
> 
> So, I'd like to hear from other groups (not just Jim :) ).   
> How many of 
> ya'll vote for:
> 1) Including another library is appropriate to get full DICOM support
> 2) Increasing our implementation to include more of DICOM's 
> intensity-related tags
> 3) Not spending more time on IO
> 
> Ragarding 1) There is no easy way to get CTN to build cross platform, 
> but I did make progress awhile ago on CMake for dcmtk.   But, it is a 
> fairly large library to start including with ITK (compared to 
> PNG)...but 
> then we'll have full support (that is, the library functions will be 
> there, but I am not certain how much our existing IO base 
> classes will 
> allow us to make us of the additional capabilities of DICOM - 
> I'd have 
> to look into this more).
> 
> Regarding 2) My concern with doing more ourselves is the 
> evolving nature 
> of the "standard."   Soon (?) a 3D standard will be out - but 
> it is only 
> slated to cover Ultrasound images.   I don't know the schedule for CT 
> and then MR related 3D standards for DICOM.   Vendors are 
> becoming more 
> complient, but anything we do will always fail for some people. 
> Additionally, we kind of decided that ITK wouldn't focus on IO, and I 
> hate duplicating effort and trying to play catch-up with 
> another group. 
>    Some of our uses are using DCMTK and ITK on their own with 
> success. 
> Okay - my bias is really showing.   The nice part about doing 
> it on our 
> own is that we don't burden the user with having to install another 
> library, and we'll have direct control of the software.
> 
> Ragarding 3) If we don't provide sufficient support at some 
> level, then 
> we perhaps look bad.  The question is what level of support.  
> Right now 
> we can read in DICOM objects (which are 2D images) and read 
> in multiple, 
> raw DICOM slices to create a volume by writing a simple 
> header.  We do 
> not offset the raw pixel values, apply the intensity windowings 
> specified in an object, map the values via any lookup table in an 
> object, automatically searching a directory/pacs-hierarchy to 
> identify 
> and reconstruct patients/studies/series/volumes, support jpeg 
> compression of the pixels, suport dicom directories within objects, 
> support overlays, support annotations, support multi-layered 
> data (e.g., 
> sometimes digital subtraction images have the unsubtracted data also 
> stored in one object), the new CAD markings, lines, curves, etc.
> 
> So, ther truly is no clear answer.   So, vote now... :)
> 
> s
> 
> -- 
> ===============================================
> Dr. Stephen R. Aylward
> Assistant Professor of Radiology
> Adjunct Assistant Professor of Computer Science
> http://caddlab.rad.unc.edu
> aylward@unc.edu
> (919) 966-9695
> 
> _______________________________________________
> Insight-developers mailing list
> Insight-developers@public.kitware.com
> http://public.kitware.com/mailman/listinfo/insight-developers
>