[Insight-developers] Re: [Insight-users] load a CT scan (DICOM)
Stephen R. Aylward
aylward@unc.edu
Fri, 13 Sep 2002 15:52:21 -0400
Cool part about the MetaImage approach is that you don't have to create
another copy of the data. You just write a text file that points to it.
We'll see how the program goes and then we can easily convert it to a IO
module in the future if it goes well.
Thanks,
Stephen
Miller, James V (Research) wrote:
> 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
>>
>
--
===============================================
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