[Insight-developers] Re: [Insight-users] load a CT scan (DICOM)

Luis Ibanez luis.ibanez@kitware.com
Fri, 13 Sep 2002 17:09:02 -0400


This is a multi-part message in MIME format.
--------------020405000208080403020603
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit


Hi Jim,

The MetaImage format just requires to create a header text file that
points to the original DICOM data. For example, I'm using the following
MetaImage header file to read directly a set of Dicom files. No data
is duplicated in this approach.

   NDims = 3
   DimSize = 512 512 41
   Position = 0 0 0
   ElementSpacing = 0.63281 0.63281 7.0
   ElementByteOrderMSB = False
   ElementType = MET_USHORT
   HeaderSize = -1
   ElementDataFile = image%04d.dcm 1 41 1


---(this header file is also attached to this message)----

This reads the following files into a 3D image:

   image0001.dcm
   image0002.dcm
   image0003.dcm
   image0004.dcm
   ...etc
   image0041.dcm

The header file was created with the MetaImageImporter but it could
have been created by hand once you know the fields that are required.


   Luis

===============================

Stephen R. Aylward wrote:
> 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.
>>
>>

--------------020405000208080403020603
Content-Type: text/plain;
 name="livertest.mha"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="livertest.mha"

NDims = 3
DimSize = 512 512 41
Position = 0 0 0
ElementSpacing = 0.63281 0.63281 7.0
ElementByteOrderMSB = False
ElementType = MET_USHORT
HeaderSize = -1
ElementDataFile = image%04d.dcm 1 41 1

--------------020405000208080403020603--