[Insight-developers] RE: [Insight-users] load a CT scan (DICOM)
Miller, James V (Research)
millerjv@crd.ge.com
Fri, 13 Sep 2002 15:38:13 -0400
If the data is not DICOM conforming, then I wouldn't worry about it
immediately (unless you have a particular device in house that doesn't
conform). I would think that we should be able to handle 80%-90% of the
cases without jumping through too many hoops.
(Admittedly, there is probably no way to handle the vendor specific
tags appropriately (other than skipping them)).
I still don't understand why a separate program is needed. Ultimately,
I want to point my app at a directory of DICOM images, browse the
patient, study, and series UIDs and select a dataset to operate on.
I would like to avoid having two copies of my data (one DICOM version and one
ITK version).
I just think that if you are putting together a program that will parse
the DICOM headers to assemble a volume, then that processing could be
in the IO object. You can still provide a stand alone program (that used
the IO object) for those cases where people want to translate their
DICOM data into something else.
An argument for writing the volume into a separate datafile is that
that processing would only have to be done once for the dataset. However,
in practise, people are not going to running algorithms again and again
and again on the same data. Ultimately, people will visit a dataset
once and run their processing on that data and then move onto the
next dataset.
> -----Original Message-----
> From: Stephen R. Aylward [mailto:aylward@unc.edu]
> Sent: Friday, September 13, 2002 2:46 PM
> To: Miller, James V (Research)
> Cc: Insight-developers (E-mail)
> Subject: Re: [Insight-users] load a CT scan (DICOM)
>
>
>
> Actually, it would really be nice if it worked this way, but
> it doesn't.
>
> CT can be acquired in slabs, interleaved, or in arterial and venous
> phases, or ... Sometimes SID is incremented when it should be,
> sometimes it isn't (often when making multiple scans to
> observe contrast
> uptake - a very common CT protocol), sometimes it is
> incremented when it
> shouldn't (making a scan appear to be 2 - even confuses our
> PACS and the
> Vitrea workstation), etc. MR gets significantly worse with
> multi-echo
> sequences, etc. And, as Steve Pieper mentioned, slice thickness
> commonly changes throughout a CT scan performed for radiation therapy
> planning...ugh...Then there are different levels of conformity to the
> standard by different manufacturers...
>
> We (aka Mark Foskey) are (is) writing a program to parse a
> directory and
> to try to put them together into a volume, but I don't think
> this should
> be part of the IO filter - a fair amount of processing is required to
> look at the multiple dicom fields needed to identify and load
> a sequence
> - and it definitely won't work all of the time. I think having a
> program to create a volume from the dicom is the way to go. Meta
> provides a nice solution until Mark's program is ready.
>
> But, please keep in mind we are open to other ideas. Originally we
> were looking at dicom libs (CTN and DCMTK), but neither
> offers a method
> for creating a 3D volume from multiple 2D slices as part of an IO
> routine. As a result, Thibaut Clemencelle wrote a nice itk IO filter
> for 2D reading which is all those dicom libs provide.
>
> I hope this helps,
> Stephen
>
>
> Miller, James V (Research) wrote:
> > I guess I just don't understand. Isn't the slice number /
> (table) location
> > information in the DICOM header.
> >
> > Shouldn't a user just be able to point the DICOM reader at
> a file, the DICOM
> > reader peeks into the header for the SeriesUID, then finds
> all the files
> > in that directory that have that SeriesUID in the header,
> for each file, find
> > the slice number or table location, and put together a nice
> little volume
> > of data?
> >
> > Now admittedly, it usually gets tricky with patient
> orientation, etc. but that
> > should be doable.
> >
> > Now MR data will be trickier, but all the scan protocal
> should be in the header
> > and hence could be handled by the DICOM reader.
> >
> >
> >
> >
> >>-----Original Message-----
> >>From: Stephen R. Aylward [mailto:aylward@unc.edu]
> >>Sent: Friday, September 13, 2002 12:50 PM
> >>To: Alberto Bert
> >>Cc: insight-users@public.kitware.com
> >>Subject: Re: [Insight-users] load a CT scan (DICOM)
> >>
> >>
> >>Hi,
> >>
> >>The answer may be simple...Sometimes dicom transfers occur in
> >>order - so
> >>the file numbers actually correspond (by luck) to how the
> >>slices should
> >>be ordered to create a 3D volume.
> >>
> >>In that case, you can use the MetaImage format to read the
> >>dicom slices
> >>to create a volume. You can use the
> >>Insight/Example/MetaImageImporter
> >>to walk you thru the process to create a MetaImage header
> >>file that will
> >>allow the slices to be loaded. Or you can write the
> >>MetaImage header
> >>file yourself. The MetaImage header format is simple and
> >>will resemble
> >>
> >>NDims = 3
> >>DimSize = 512 512 <Enter#OfSlicesHere>
> >>ElementSpacing = <EnterXPointSize> <EnterYPointSize>
> >><EnterSliceSpacing>
> >>HeaderSize = -1
> >>ElementType = MET_USHORT
> >>ElementByteOrderMSB = True
> >>ElementDataFile = LIST
> >><EnterFileNameOfFirstSlice>
> >><EnterFileNameOFSecondSlice>
> >><EnterFileNameOfThirdSlice>
> >>.
> >>.
> >>.
> >>
> >>
> >>This is assuming the slices are 512x512 (most CT scans) of Unsigned
> >>Shorts (valid for most CT dicom), and the Byte Ordering is MSB (the
> >>default for most dicom). By setting HeaderSize = -1 the
> >>program will
> >>automatically calculate the header size for each slice under the
> >>assumption that the pixel data occurs at the end of each
> slice's file
> >>(which is generally true for dicom).
> >>
> >>HOWEVER, DICOM does not guarantee order of delivery of slices
> >>- so, the
> >>file numbering might be absolutely unrelated to how the
> >>slices should be
> >>ordered to create a 3D volume. You can try to figure out
> >>the ordering,
> >>but that is really tedious. Otherwise, we are working on a
> >>program to
> >>automatically generate 3D MetaImages from a directory of
> dicom files.
> >>It may be a few weeks before that program is ready.
> >>
> >>I hope this helps,
> >>Stephen
> >>
> >>Alberto Bert wrote:
> >>
> >>>Hi all,
> >>>
> >>>I'm interested in loading a CT (comput. tomography) scan in itk.
> >>>I know that DicomImageIO can get DICOM file (medical
> images standard
> >>>format), but in this case each slice (2D images at
> >>
> >>specified z, forming
> >>
> >>>the 3D image when in stak) is in a separate file. I mean, I
> >>
> >>would like
> >>
> >>>to read several 2D DICOM files (each containing a slice)
> >>
> >>and organizing
> >>
> >>>them to form a 3D image for itk.
> >>>
> >>>Any one can help me?
> >>>
> >>>Alberto
> >>>_______________________________________________
> >>>Insight-users mailing list
> >>>Insight-users@public.kitware.com
> >>>http://public.kitware.com/mailman/listinfo/insight-users
> >>
> >>
> >>--
> >>===============================================
> >>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-users mailing list
> >>Insight-users@public.kitware.com
> >>http://public.kitware.com/mailman/listinfo/insight-users
> >>
> >
>
>
> --
> ===============================================
> 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
>