[Insight-developers] ImageFileReader Bug 0007520 and some considerations/ideas about ImageSeriesReader/Writer

Iván Macía imacia at vicomtech.org
Mon Nov 17 11:52:36 EST 2008



> -----Mensaje original-----
> De: Mathieu Malaterre [mailto:mathieu.malaterre at gmail.com]
> Enviado el: lunes, 17 de noviembre de 2008 17:23
> Para: Iván Macía
> CC: Insight Developers
> Asunto: Re: [Insight-developers] ImageFileReader Bug 0007520 and some
> considerations/ideas about ImageSeriesReader/Writer
> 
> On Mon, Nov 17, 2008 at 3:34 PM, Iván Macía <imacia at vicomtech.org> wrote:
> > Dear all,
> >
> >
> >
> > We are trying to read slice by slice a DICOM series. We cannot use
> > ImageSeriesReader because the series is heterogeneus in size and it does
> not
> > correspond to a 3D volume. When trying to read the last image with
> > ImageFileReader an exception occurs in
> > ImageFileReader::EnlargeOutputRequestedRegion()
> >
> >
> >
> > "ImageIO returns IO region that does not fully contain the requested
> region"
> >
> >
> >
> >
> > Having a look at the source of the problem, ImageFileReader fails when
> > trying to read a second image that is smaller that the previous image
> read.
> > The problem is that the LargestPossibleRegion is assigned the new
> smaller
> > size but the RequestedRegion is not. Having a look at Mantis I found a
> > related bug
> >
> >
> >
> > Bug 0007520: failed propagation of largestPossibleRegion to
> > requestedPossibleRegion
> >
> >
> >
> > Probably this can be solved with a call to
> > output->SetRequestedRegionToLargestPossibleRegion() at the end of
> > ImageFileReader::GenerateOutputInformation() after setting
> > output->SetLargestPossibleRegion().
> >
> >
> >
> > On the other hand, I wanted to know if there are some plans to extend
> the
> > capabilities of ImageSeriesReader and ImageSeriesWriter. We are
> developing a
> > viewer for a DICOM PACS and found many different types of series that
> does
> > not correspond to the usual ITK concept of a series consisting of slices
> of
> > a 3D images. For example, we have found:
> >
> >
> >
> > -          Series of 2D images as a time series (cine) or single images
> with
> > multiple frames (these all can be considered as multi-frame).
> >
> > -          Series with intermixed volumes, such as those that show
> different
> > times of a contrast-enhanced volume. These could also be considered as
> 3D+t.
> >
> > -          Series that represent a reslicing of the original volume and
> show
> > a preview image.
> >
> >
> >
> > and even more exotic series such as those consisting of
> >
> >
> >
> > -          Intermixing of multi-frame and non-multiframe 2D images in
> the
> > same series.
> >
> > -          Series with different pixel types (for example the preview
> image
> > of the reconstruction can be RGB whereas the rest is short for CT or
> ushort
> > for MR).
> >
> > -          Images of type RGB<short>.
> >
> >
> >
> > I have found some methods in GDCM 1.x that can deal with some of these
> > features, such as gdcm::SerieHelper::SplitOnOrientation() and we had to
> > develop some of heuristics by our own, but wanted to know if there were
> some
> > plans to add functionality for this analysis in ITK. One idea could be
> to
> > develop a class that could take the file names of a series and analyse
> them
> > in order to split them in groups according to some property.
> 
> You have used itk::GDCMSeriesFilenames, right ? If this is not working
> for you, please send the full src code + demo data sample + expected
> output. As you may have realize this is a non-trivial task to come up
> with a general solution, as multiframes DICOM is totally different
> from isotropic volume in ITK.
> 
> Thanks,
> --
> Mathieu

Dear Mathieu,

I am aware that doing what I pretend probably needs a full rework of
GDCMSeriesFilenames. I was even thinking on making a contribution to IJ
myself (I am really busy at the moment though, so it would have to wait a
bit). I just wanted to discuss if this was interesting or not, if it had
been already considered and how it could be done.

I use GDCMSeriesFilenames for parsing the files in search for the different
series in a directory but then I analyse the coherency in the files of the
series with my own code (GDCM based).

On the other hand, the problem with ImageFileReader is a different one,
corresponding to a bug considering the expected behaviour.

Thanks,

Ivan 




More information about the Insight-developers mailing list