[Insight-developers] Undefined behaviors of ImageSeriesReader

[Bradley Lowekamp]

Hello,

	I am planning on committing this bug fix this afternoon if there are  
no objections.

I have submitted an experimental build with the my test, it summarizes  
the behavior well:

http://www.cdash.org/CDash/testDetails.php?test=28416924&build=390282


This should go along way to robustify this reader for different input  
files, when the dimensions aren't the normal and expected.

The one problem which still remains is that this filter basically  
doesn't function when the Image is 1D. Is there a concept check which  
could be used to ensure that this ImageSeriesReader does not get  
instantiated with an image of this dimension?

Brad

On Jul 29, 2009, at 2:03 PM, Lowekamp, Bradley (NIH/NLM/LHC) [C] wrote:

> 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
>
>
> <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/20090730/a108e5bc/attachment.htm>