[Insight-developers] GDCM eventually replacing DICOMImageIO2

[Lorensen, William E (Research)]

The rescaling for PET is specific for each image, not for the whole volume.
I think it can be treated the same for all dicom data as long as the slope
and offset are applied to each image.

-----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
> 



_______________________________________________
Insight-developers mailing list
Insight-developers at itk.org
http://www.itk.org/mailman/listinfo/insight-developers