[Insight-developers] Undefined behaviors of ImageSeriesReader

[Bradley Lowekamp]

Thanks Bill,  that was the expect response.

I was able to make a couple small changes to ImageSeriesReader so that  
the behavior of reading a single image is the same as ImageFileReader.  
I believe this is the most logical defined behavior, before in these  
cases we had stack corruption or an exception. I have added a test  
called itkImageSeriesReaderDimensionsTest, and submitted an  
experimental build from victoria with the changes and new test. All  
relevant tests pass.

Onto looking at the cases of where the ImageSeriesReader is actually  
reading a series of images.

1)  IO Dimension (from file, minus trailing ones) >= ImageDimension  
(tempted image type)

This generates an exception.

2)  IO Dimension (from file, minus trailing ones) - 1 ==  
ImageDimension (tempted image type)

This is the expected usage and behaves correctly.

3) IO Dimension (from file, minus trailing ones) - 1 <= ImageDimension  
(tempted image type)

This currently works with the following behavior: Consider reading a  
series of DICOM files into a 3D image. If each file has the size [256,  
1, 1] then the size of the output image for the ImageSeriesReader is  
[256, N, 1] where N is the number of images in the series.


Are these behaviors correct?

Brad

On Jul 29, 2009, at 11:26 AM, Bill Lorensen wrote:

> protected means that a subclass can access the variable. We can't
> change it since someone may have created a subclass.
>
> This brings up a good point. When we review code in the Review
> directory, we should try to keep member data private and provide
> access to that data (if required) with Get methods. I just added this
> to the Review/IJ checklist:
> http://www.itk.org/Wiki/ITK_Release_Schedule#Check-list_for_Moving_Code_from_IJ_to_Review_and_from_Review
>
> Bil
>
> On Wed, Jul 29, 2009 at 10:55 AM, Bradley
> Lowekamp<blowekamp at mail.nih.gov> wrote:
>> 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
>>
>>
>> _______________________________________________
>> 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


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