[Insight-developers] Re: [Insight-users] load a CT scan (DICOM)
Stephen R. Aylward
aylward@unc.edu
Fri, 13 Sep 2002 14:45:58 -0400
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