[Insight-developers] GDCM eventually replacing DICOMImageIO2

[Miller, James V (Research)]

The slope and offset are more that just "for display".  They indicate
how to convert from the (usually) 16 bit storage format to the appropriate
dynamic range of the data.  For CT, the slope and offset are usually
1 and -1024 (for data on some PACS systems, the slope may be 2 and the 
offset -2048).  Applying the slope and offset is important for CT to 
convert the storage data to Hounsfeld units. Each vendor could use a
different slope and offset.  For proper processing, we should always 
present CT to ITK in Hounsfeld units.

For PET the situation is more insipid.  PET data cannot be stored in 
16 bits without loss of information.  To limit the loss, each PET slice
is scaled independently to fit in 16 bits.  So each PET slice in the 
series will have a different slope and intersept.

In the DICOMParser code, we took the position that the pixel data returned
from the library would already have the appropriate slope and offset 
applied.  This means that CT data is always presented to ITK in Hounsfeld
units and PET data is reconciled to a common dynamic range.

To apply the slope and offset correctly, we looked at the magnitude of the 
slope.  If slope was exactly 1, we kept the pixel data as an integer.
If the slope was different from 1, we returned the pixel data as float.
The ITK readers will convert the pixel data to whatever datatype the user
requested but the DICOM library always returns the data in the most
appropriate type.

Jim





-----Original Message-----
From: Mathieu Malaterre [mailto:mathieu.malaterre at kitware.com]
Sent: Friday, November 19, 2004 5:22 PM
To: Miller, James V (Research)
Cc: insight-developers at public.kitware.com
Subject: Re: [Insight-developers] GDCM eventually replacing
DICOMImageIO2


Miller, James V (Research) wrote:
> Another thing to consider.  We should verify that GDCM returns a
> volume in the same order as DICOMImageIO2.  I'd have to dig through
> the code to determine whether we order head-to-toe or toe-to-head
> (though I think it is toe-to-head, or towards positive z).

That's what is done in GDCM currently. But I can still do a double check.

> Also, for PET data, does GDCM produce float data?  Each image in a
> PET series will have a different "slope" and "offset".  These must 
> be applied to each image prior to putting them together in a volume.


Interesting. Why PET only ?
I am not familiar with PET modality but for CT, there is a Contrast 
Agent (absolute value). Thus this would mean there will be 'hidden' 
rescale (only for PET) which would make Contrast Agent meaningless.

I would just expose Slope/Offset to user interface and if all he want is 
to display a nice image then he should explicitely use a RescaleFilter. 
Thus this would still allow people to use the Constrast Agent value from 
the DICOM header.

Is there something I am missing with PET modality ?

Thanks
Mathieu



> -----Original Message-----
> From: Lorensen, William E (Research) [mailto:lorensen at crd.ge.com]
> Sent: Friday, November 19, 2004 4:52 PM
> To: 'Mathieu Malaterre'
> Cc: insight-developers at public.kitware.com
> Subject: RE: [Insight-developers] GDCM eventually replacing
> DICOMImageIO2
> 
> 
> Actually, using the filename is not useful. As you say, the names are
> arbitrary.
> 
> Multiple series in a directory are certainly common. I have not seen
> multiple studies although this is certainly possible.
> 
> Look at the API for DICOMSeriesFileNames for the handling of multiple
> series.
> 
> Bill
> 
> 
> -----Original Message-----
> From: Mathieu Malaterre [mailto:mathieu.malaterre at kitware.com]
> Sent: Friday, November 19, 2004 4:45 PM
> To: Lorensen, William E (Research)
> Cc: insight-developers at public.kitware.com
> Subject: Re: [Insight-developers] GDCM eventually replacing
> DICOMImageIO2
> 
> 
> 
> 
>>For one, the GDCMSeriesFilenames does not seem to handle mutiple series in
> 
> a
> 
>>directory.This is a common occurrence. The API of DICOMSeriesFilenames to
>>handle this is easy to use.
> 
> 
> That's definitely one thing on my TODO list. It shouldn't take me long 
> to implement it, once I know the choices:
> 
> - How do I order when there is a mixture of DICOM serie and DICOM study
> - What should I do when both serie/study have the same number
> - What is considerer to be the first serie when there are multiple 
> series ? Is  it determine by the first DICOM image read...
> 
> 
> 
>>Also, in DICOMSeriesFileNames, the sorting of the files can be ascending
> 
> or
> 
>>descending. This may or not be a useful feature.
> 
> 
> Well, I am not convinced this is usefull and could maybe conduct people 
> into error.
> 
> What's done currently in GDCMSeries is a strategy approach:
> 
> - We read all of our images, then try to order following:
> 
> 1. What I called /Jolinda's/ algorithm, we extract image position, we do 
> some math to determine vector normal of 2D plane, and then order
accordingly
> 
> 2. If 1) fail (no image position...) we order using 'Image Number' this 
> is a DICOM tag
> 
> 3. If 2) fail, we do by filenames, hopefully the files are order properly.
> 
> For me this make much more sense, since we don't want people starting to 
> work on a 3D image 'inside out'. Or worse, since DICOM does not define 
> filename convention (see e-film convention), slices could be 
> interchanged, putting slices at the wrong place.
> 
> 
> Mathieu
> 
> _______________________________________________
> Insight-developers mailing list
> Insight-developers at itk.org
> http://www.itk.org/mailman/listinfo/insight-developers
>