We do the same thing in Slicer. The vtkITKArchetypeImageSeriesReader deduces what to do from a single representative file. An earlier version exists ion InsightApplications/vtkITK.<br><br><div><span class="gmail_quote">On 5/10/07,
<b class="gmail_sendername">kent williams</b> <<a href="mailto:norman-k-williams@uiowa.edu">norman-k-williams@uiowa.edu</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
This behavior is my fault, since GE4ImageIO was a conversion of code from<br>the BRAINS2 application, which worked this way. I can understand how that<br>would interact poorly with the ImageSeriesReader.<br><br>It brings up an issue that has bothered me about how Image IO works in ITK:
<br>While it promises and delivers a fair amount of image format independence,<br>it exposes the difference between monolithic image file formats and image<br>formats that are built from a series of 2D image files.<br><br>
What I've started for brains2 is a separate layer of abstraction that takes<br>a path (a filename, a directory name), deduces how that can be translated<br>into an image volume, and then loads it.<br><br>In most ITK-based research software, the developer knows the incoming image
<br>format, and can choose whether to use an image series reader or an image<br>reader. That's all well and good, but in the case of more general image<br>processing applications, you want to be able to 'take all comers.'
<br><br>And really, there's no good reason for using the same 10 or 15 lines of<br>boilerplate code every time you want to open a file. Much better to write<br>it once and re-use it everywhere. For novices, knowing which 10 or 15 lines
<br>of boilerplate code to drop in is part of the learning curve to using ITK --<br>one that isn't strictly necessary.<br><br><br>On 5/9/07 5:05 PM, "Neil Weisenfeld" <<a href="mailto:neil@bwh.harvard.edu">
neil@bwh.harvard.edu</a>> wrote:<br><br>> Hi all,<br>><br>> (devs maybe read the last paragraph)<br>><br>> Here's why using GE4ImageIO with itkImageSeriesReader causes core-dumps:<br>><br>> itkImageSeriesReader reader attempts to read in an image slice by
<br>> slice, however GE4ImageIO, when given the filename of a single slice,<br>> ***actually reads in the whole volume***<br>><br>> So while itkImageSeriesReader correctly allocates an output volume<br>> for the slice dimensions x #slices, it then reads the entire volume
<br>> #slices many times obviously (well, not obviously, but see below)<br>> trampling over unallocated memory.<br>><br>> One solution is to use GE4ImageIO with itkImageReader, rather than<br>> itkImageSeriesReader, supply only the *first* filename in the series,
<br>> and then let the internal magic pick up all of the slices.<br>><br>> Maybe stylistically, it would be good if the loop in<br>> itkImageSeriesReader that actually copies pixels checked both the<br>> input AND output arrays for IsAtEnd(). That would, at least, avoid
<br>> the core dump.<br>><br>><br>> Regards,<br>> Neil<br>><br>><br>><br>><br>><br>><br>><br>> On May 8, 2007, at 2:29 PM, Neil Weisenfeld wrote:<br>><br>>><br>>> Hi all,
<br>>><br>>> I'm trying to read some Signa 4.x images using the GE4ImageIO and<br>>> this seems to result in:<br>>><br>>> *** glibc detected *** free(): invalid pointer: 0x0000002a98ab1010 ***
<br>>><br>>> which is coming from the destruction of itkImportImageContainer.<br>>><br>>><br>>> An e-mail that someone sent to this list in January about reading<br>>> Signa 5.x images yielded the response that the Insight Applications
<br>>> program ConvertBetweenFileFormats does this, however it seems to me<br>>> that ConvertBetweenFileFormats uses GDCM to read DICOM series<br>>> images, but not Signa(?)<br>>><br>>> Furthermore, the tests included for GE4ImageIO only test reading of
<br>>> a single slice, not a series, so I'm wondering if there is actually<br>>> a bug.<br>>><br>>> Here's the code excerpt. ***NOTE: I've tried this both via factory<br>>> traversal and by specifying a GE4ImageIO "manually" and both
<br>>> produce the same results.<br>>><br>>> I'd appreciate any suggestions and apologise if I did something<br>>> incredibly stupid.<br>>><br>>><br>>><br>>> Regards,<br>
>> Neil<br>>><br>>><br>>><br>>><br>>> itk::ObjectFactoryBase::RegisterFactory<br>>> ( itk::GEAdwImageIOFactory::New() );<br>>> itk::ObjectFactoryBase::RegisterFactory<br>
>> ( itk::GE4ImageIOFactory::New() );<br>>> itk::ObjectFactoryBase::RegisterFactory<br>>> ( itk::GE5ImageIOFactory::New() );<br>>><br>>> typedef unsigned short PixelType;<br>>> typedef itk::Image< PixelType, 3> ImageType;
<br>>> typedef itk::NumericSeriesFileNames GeneratorType;<br>>> typedef itk::ImageSeriesReader< ImageType > SeriesReaderType;<br>>><br>>> GeneratorType::Pointer names = GeneratorType::New();
<br>>> names->SetStartIndex( start );<br>>> names->SetIncrementIndex( inc ) ;<br>>> names->SetEndIndex( end );<br>>> names->SetSeriesFormat( inpPat.c_str() );<br>>><br>>> SeriesReaderType::Pointer reader = SeriesReaderType::New();
<br>>> reader->SetFileNames( names->GetFileNames() );<br>>><br>>> try<br>>> {<br>>> reader->SetDebug(true);<br>>> reader->Update();<br>>><br>>><br>
>> code trace:<br>>><br>>> #0 0x000000329cf2e21d in raise () from /lib64/tls/libc.so.6<br>>> (gdb) bt<br>>> #0 0x000000329cf2e21d in raise () from /lib64/tls/libc.so.6<br>>> #1 0x000000329cf2fa1e in abort () from /lib64/tls/libc.so.6
<br>>> #2 0x000000329cf63291 in __libc_message () from /lib64/tls/libc.so.6<br>>> #3 0x000000329cf68eae in _int_free () from /lib64/tls/libc.so.6<br>>> #4 0x000000329cf691f6 in free () from /lib64/tls/libc.so.6
<br>>> #5 0x000000329fcae20e in operator delete () from /usr/lib64/libstdc<br>>> ++.so.6<br>>> #6 0x0000000000441e15 in ~ImportImageContainer (this=0x659f70)<br>>> at /opt/x86_64/pkgs/itk/3.2.0/gcc-release/include/
<br>>> InsightToolkit/Common/itkImportImageContainer.txx:45<br>>> #7 0x0000002a967ecf29 in itk::Object::UnRegister ()<br>>> from /opt/x86_64/pkgs/itk/3.2.0/gcc-release/lib/InsightToolkit/<br>>>
libITKCommon.so.3.2<br>>> #8 0x00000000004324e4 in<br>>> itk::SmartPointer<itk::ImportImageContainer<unsigned long, unsigned<br>>> short><br>>>> ::UnRegister (this=0x65bc20)<br>>> at /opt/x86_64/pkgs/itk/3.2.0/gcc-release/include/
<br>>> InsightToolkit/Common/itkSmartPointer.h:148<br>>> #9 0x0000000000432109 in ~SmartPointer (this=0x65bc20)<br>>> at /opt/x86_64/pkgs/itk/3.2.0/gcc-release/include/<br>>> InsightToolkit/Common/itkSmartPointer.h:65
<br>>> #10 0x0000000000440373 in ~Image (this=0x65ba60)<br>>> at /opt/x86_64/pkgs/itk/3.2.0/gcc-release/include/<br>>> InsightToolkit/Common/itkImage.h:365<br>>> #11 0x0000002a967ecf29 in itk::Object::UnRegister ()
<br>>> from /opt/x86_64/pkgs/itk/3.2.0/gcc-release/lib/InsightToolkit/<br>>> libITKCommon.so.3.2<br>>> #12 0x0000002a967f8143 in itk::ProcessObject::~ProcessObject$base ()<br>>> from /opt/x86_64/pkgs/itk/3.2.0/gcc-release/lib/InsightToolkit/
<br>>> libITKCommon.so.3.2<br>>> #13 0x0000000000430351 in ~ImageSource (this=0x659db0)<br>>> at /opt/x86_64/pkgs/itk/3.2.0/gcc-release/include/<br>>> InsightToolkit/Common/itkImageSource.h:178
<br>>> #14 0x0000000000448e74 in ~ImageFileReader (this=0x659db0)<br>>> at /opt/x86_64/pkgs/itk/3.2.0/gcc-release/include/<br>>> InsightToolkit/IO/itkImageFileReader.txx:46<br>>> #15 0x0000002a967ecf29 in itk::Object::UnRegister ()
<br>>> from /opt/x86_64/pkgs/itk/3.2.0/gcc-release/lib/InsightToolkit/<br>>> libITKCommon.so.3.2<br>>> #16 0x00000000004462b0 in<br>>> itk::SmartPointer<itk::ImageFileReader<itk::Image<unsigned short,
<br>>> 3u>, itk::DefaultConvertPixelTraits<unsigned short> > >::UnRegister<br>>> (this=0x7fbfffecc0)<br>>> at /opt/x86_64/pkgs/itk/3.2.0/gcc-release/include/<br>>> InsightToolkit/Common/itkSmartPointer.h:148
<br>>> #17 0x0000000000444069 in ~SmartPointer (this=0x7fbfffecc0)<br>>> at /opt/x86_64/pkgs/itk/3.2.0/gcc-release/include/<br>>> InsightToolkit/Common/itkSmartPointer.h:65<br>>> #18 0x000000000043e928 in
<br>>> itk::ImageSeriesReader<itk::Image<unsigned short, 3u><br>>>> ::GenerateData (this=0x6428a0)<br>>> at /opt/x86_64/pkgs/itk/3.2.0/gcc-release/include/<br>>> InsightToolkit/IO/itkImageSeriesReader.txx:290
<br>>> #19 0x0000002a967f9516 in itk::ProcessObject::UpdateOutputData ()<br>>> from /opt/x86_64/pkgs/itk/3.2.0/gcc-release/lib/InsightToolkit/<br>>> libITKCommon.so.3.2<br>>> #20 0x0000000000428421 in main (argc=6, argv=0x7fbffff518)
<br>>> at /home/ch116471/projects/svnwrk/crkit.org/trunk/tools/code/<br>>> crlSlicesToVolume.cxx:80<br>>><br>>> _______________________________________________<br>>> Insight-users mailing list
<br>>> <a href="mailto:Insight-users@itk.org">Insight-users@itk.org</a><br>>> <a href="http://www.itk.org/mailman/listinfo/insight-users">http://www.itk.org/mailman/listinfo/insight-users</a><br>><br>> _______________________________________________
<br>> Insight-developers mailing list<br>> <a href="mailto:Insight-developers@itk.org">Insight-developers@itk.org</a><br>> <a href="http://www.itk.org/mailman/listinfo/insight-developers">http://www.itk.org/mailman/listinfo/insight-developers
</a><br><br>_______________________________________________<br>Insight-developers mailing list<br><a href="mailto:Insight-developers@itk.org">Insight-developers@itk.org</a><br><a href="http://www.itk.org/mailman/listinfo/insight-developers">
http://www.itk.org/mailman/listinfo/insight-developers</a><br></blockquote></div><br>