[Insight-developers] Dicom
Stephen R. Aylward
aylward@unc.edu
Tue, 17 Sep 2002 09:52:11 -0400
That would be great. Some of the tag reading function is in the
DicomIO library, but probably not as good as his system.
Does it require a dicom dictionary or is such hard coded?
If they release it, we can take-on integrating it into itk (after we
finish our validation stuff).
Either way it would be nice having a cross-platform directory parser.
We could read in stacks of PNG etc.
Now about you voting.... :)
s
Miller, James V (Research) wrote:
> (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
>>
>
> _______________________________________________
> Insight-developers mailing list
> Insight-developers@public.kitware.com
> http://public.kitware.com/mailman/listinfo/insight-developers
--
===============================================
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