[Insight-developers] GDCM eventually replacing DICOMImageIO2
Mathieu Malaterre
mathieu.malaterre at kitware.com
Fri Nov 19 17:21:50 EST 2004
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
>
More information about the Insight-developers
mailing list