[Insight-users] Reading DICOM time series study

[Mark Wyszomierski]

Martin,

My experience has been that Temporal Position Identifier / Number of
Temporal Position tags are rarely present. I have only seen them
created by Phillips scanners. I would suggest using image time +
series time but I have also seen siemens cases for which duplicate
image times have been present for images in the same series. If you
are targeting images from only a certain scanner I know that the two
tags you mentioned will work for the sorting. But if you want a method
that will consistently sort datasets from multiple manufacturers, it
is best to rely on a few different tags that can be swapped when
others are not present.

I have no experience with ITK's DICOM IO classes, but I just wanted to
throw this out there for you,

Mark



On 7/12/05, Martin Kavec <kavec at messi.uku.fi> wrote:
> Thanks for the reply, Karthik.
> 
> Your code may, for sure, be a valid solution. However, after I read your
> message, I told myself there must be an information related to the time
> series in the DICOM header of an image. So I randomly grabbed an image from
> an fMRI time series and found following two (correct) tags
> 
> 0020,0100  Temporal Position Identifier: 52
> 0020,0105  Number of Temporal Positions: 120
> 
> Everything what's needed to construct the 4D image is there, so why not to use
> it? Quoting myself: Is this a limitation of ITK's DICOM image reader
> implementation? I would still be tempted to say: yes.
> 
> What do you say?
> 
> Regards,
> Martin
> 
> On Monday 11 July 2005 14:45, Karthik Krishnan wrote:
> > I don't think it is not a limitation of the dicom image reader. You need
> > to do that with your code.
> >
> > You could for instance read all the dicom series in the directory and
> > use the JoinSeriesImageFilter to create a 4D image from the 3D images
> > you just read. It is not a limitation of the dicom reader because a
> > dicom file is  a 2D file. So the ImageSeriesReader which passes the set
> > of filenames to the GDCMImageIO has to be instantiated over an image of
> > dimension 2+1.
> >
> > You could do something like
> >     const SeriesIdContainer & seriesUID = nameGenerator->GetSeriesUIDs();
> >     SeriesIdContainer::const_iterator seriesItr = seriesUID.begin();
> >     SeriesIdContainer::const_iterator seriesEnd = seriesUID.end();
> >     while( seriesItr != seriesEnd )
> >       {
> >       seriesReader->SetFileNames( nameGenerator->GetFileNames(
> > seriesItr->c_str() ) );
> >       seriesReader->Update();
> >       joinSeriesFilter->SetInput( i++, seriesReader->GetOutput() );
> >       seriesItr++;
> >       }
> >
> > my4DImage = joinSeriesFilter->GetOutput();
> >
> > Thanks
> > karthik
> >
> > Martin Kavec wrote:
> > >Hi,
> > >
> > >I have a time series (fMRI, bolus tracking) studies in DICOM format, which
> > > I am trying to read in. I gave a brief trial test to
> > >DicomSeriesReadImageWrite2.cxx from Examples/IO. Although I changed the
> > >Dimension = 4, the output Analyze format image is 3D only. I assume that
> > >internal itkImage dimension is also 3D.
> > >
> > >Is this a limitation of ITK's DICOM image reader implementation?
> > >
> > >Regards.
> > >
> > >Martin
> > >_______________________________________________
> > >Insight-users mailing list
> > >Insight-users at itk.org
> > >http://www.itk.org/mailman/listinfo/insight-users
> _______________________________________________
> Insight-users mailing list
> Insight-users at itk.org
> http://www.itk.org/mailman/listinfo/insight-users
>