[Insight-developers] Dicom

[Stephen R. Aylward]

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