[Insight-developers] Undefined behaviors of ImageSeriesReader

[Bradley Lowekamp]

I am unsure of the guidelines for changing protected member variable.  
ImageSeriesReader has a variable named m_NumberOfDimensionsInImage.  
This is variable would be better described as something like  
m_MovingSliceDimension... Can this be done for a protected variable?  
Otherwise I'll just add comment to the header.

Thanks,
Brad


On Jul 29, 2009, at 12:24 AM, Lowekamp, Bradley (NIH/NLM/LHC) [C] wrote:

> Greetings,
>
> 	Thank you Luis for addressing bug 9205:
> http://public.kitware.com/Bug/view.php?id=9205
>
> In my effort to be completely examine the issue by looking at the  
> behavior of itkImageSeriesReader with regards to the dimensions in  
> the image files not matching expectations I became overwhelmed.
>
> First consider the case when only _one_ image is specified.
>
> 1)  IO Dimension (from file) -1 == ImageDimension (tempted image type)
>
> This is what's expected, but handeling of IO Dimensions padded with  
> 1's was not handled correctly. Should work now with Luis commit.
>
> 2)  IO Dimension (from file) == ImageDimension (tempted image type)
>
> This still does not work. Wrote a test which fails.
>
> 3) IO Dimension (from file) -1 < ImageDimension (tempted image type)
>
> I am unsure if this would fail, still need to write a test
>
> 4)  IO Dimension (from file) > ImageDimension (tempted image type)
>
> This works as the ImageFileReader takes care to the dimensionality  
> issues. It'll truncate the extra dimensions.
>
>
> The one case which is really unclear to me is case 2. What is the  
> expected behavior?  Consider this specific example,  
> itk::ImageSeriesReader<Image<float,3> >, where its input is set to a  
> single image file which also happens to be 3D, say with a size of  
> [10, 10, 10]. Is the largest region from the series reader expected  
> to be [10, 10, 10] or [10, 10, 1].
>
>
> Then I still need to look at the behavior for multiple images under  
> similar cases.
>
> Thanks,
> Brad
>
>
>
> <ATT00001.txt>

========================================================
Bradley Lowekamp
Lockheed Martin Contractor for
Office of High Performance Computing and Communications
National Library of Medicine
blowekamp at mail.nih.gov


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.itk.org/mailman/private/insight-developers/attachments/20090729/d2336b34/attachment.htm>