[Insight-developers] failing itkImageFileReaderDimensionsTest_MHD

[Wes Turner]

Bradley,

I found one code error that I checked in -- a bad file name in the
last write -- and I also found that by adding a reader update before
the 4D->3D conversion code the test both passes and doesn't hang my
VS9 build.  This is now checked in along with a comment that you are
continuing to work the issue.  This may be a stop-gap, but at least it
allows the dashboard to run while you look into it.

If you need a Microsoft (or Linux, or Mac) test platform before you
check in your change, feel free to send your patch to me before you
commit it and I can test it out for you.

- Wes

On Mon, May 18, 2009 at 2:38 PM, Bradley Lowekamp
<blowekamp at mail.nih.gov> wrote:
> There are bugs in the ImageFileReader related to reading of images where
> dimensions don't match. It can be broken into the following cases:
>
> 1) IO Dimension (from file) == ImageDimension (tempted image type)
> This works good, it's the normal things to do.
> 2) IO Dimension < ImageDimension
> ImageSeriesReader makes use of this. When reading 2D slices into a 3D image
> it requests ImageFileReader regions with size [x, y, 1]. And
> ImageFileReader::GenerateOutputInformation pads the size of the output
> image's LargestPossibleRegion with 1s. This works too, I don't see any
> problems. (Excluding direction cosine issues)
> 3) IO Dimension > ImageDimension
> 3a) If the IORegion's size is padded with 1s after ImageDimension, then
> currently should work with all file types. For example if a 3D image file
> has size [x,y,1] then it can be read into a 2D image with size [x,y]
>
> 3b) If the IORegions's size ends in non-one values, we can have problems,
> like segfaults. This is because the size of the buffers don't match, and
> ImageIO object will over write the image buffer.
> However the ImageIO classes which support streaming appear to handle this
> case correctly, by padding the region size with 1s.
>
> My proposed solution is to
> modify ImageIOBase::GenerateStreamableReadRegionFromRequestedRegion to
> actually return the full dimensionality of the image. This reflects what the
> ImageIO can actually do. Then in
> ImageFileReader::EnlargeOutputRequestedRegion and a check to make sure this
> case is not occurring.
>
>
> On May 16, 2009, at 3:39 PM, Lowekamp, Bradley (NIH/NLM/LHC) [C] wrote:
>
> This is my doing, I should be checking the fix in on monday.
>
> http://www.cdash.org/CDash/testSummary.php?project=2&name=itkImageFileReaderDimensionsTest_MHD&date=2009-05-16
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Please keep messages on-topic and check the ITK FAQ at:
> http://www.itk.org/Wiki/ITK_FAQ
>
> Follow this link to subscribe/unsubscribe:
> http://www.itk.org/mailman/listinfo/insight-developers
>
> ========================================================
>
> Bradley Lowekamp
>
> Lockheed Martin Contractor for
>
> Office of High Performance Computing and Communications
>
> National Library of Medicine
>
> blowekamp at mail.nih.gov
>
>
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Please keep messages on-topic and check the ITK FAQ at:
> http://www.itk.org/Wiki/ITK_FAQ
>
> Follow this link to subscribe/unsubscribe:
> http://www.itk.org/mailman/listinfo/insight-developers
>
>



-- 
Wesley D. Turner, Ph.D.
Kitware, Inc.
R&D Engineer
28 Corporate Drive
Clifton Park, NY 12065-8662
Phone: 518-371-3971 x120