[Insight-developers] Dicom
Miller, James V (Research)
millerjv@crd.ge.com
Tue, 17 Sep 2002 10:37:46 -0400
The parser itself does not have a dictionary it just understands the syntax
of DICOM. Think of it like the SAX XML parser. It just understands the syntax
of DICOM and calls callbacks for each group/element tags
A "reader" would then register a callback of the group/element tags that it
wants to be told about. So the reader would have to know what DICOM group/element
tags that it wants to be told about. So implictly it has a "dictionary" of what
it wants. The parser, however, just understands the syntax and not the semantics
of group/element tags.
> -----Original Message-----
> From: Stephen R. Aylward [mailto:aylward@unc.edu]
> Sent: Tuesday, September 17, 2002 9:52 AM
> To: Miller, James V (Research)
> Cc: Insight-Developers (E-mail)
> Subject: Re: [Insight-developers] Dicom
>
>
> 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
>