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

[Miller, James V (Research)]

Can the MetaImage format handle the "intensity offset" that can be
encoded in DICOM images?

For instance, signed data with a known range that is stored as unsigned data 
(so you need to apply additive offset).




> -----Original Message-----
> From: Luis Ibanez [mailto:luis.ibanez@kitware.com]
> Sent: Friday, September 13, 2002 5:09 PM
> To: Miller, James V (Research)
> Cc: Stephen R. Aylward; Insight-developers (E-mail)
> Subject: Re: [Insight-developers] Re: [Insight-users] load a CT scan
> (DICOM)
> 
> 
> 
> 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.
> >>
> >>
>