[Insight-developers] bug: 9212 itkImageFileReader modified

[Bradley Lowekamp]

Hello all,

	I just checked in a fix, to enable the reading of the first "slice"  
of a higher dimension into a lower dimension itkImage with out  
throwing an exception or over running a buffer:

http://public.kitware.com/cgi-bin/viewcvs.cgi/Code/IO/itkImageFileReader.txx?root=Insight&r1=1.85&r2=1.86&sortby=date

Consider the case of reading a 3D image in to an 2D itk::Image, when  
the reader can't stream (most of the time) the reader will have to  
read the entire 3D data set. The fix was to create a temporary buffer  
the size of the 3D image and then copy it, into the itk::Image. There  
was also a couple of style/maintenance type changes made too.

As this code is used regularly, and additional set of eyes to look  
through the changes would be good. Let me know if you have an comments  
or questions.

Thanks,
Brad

On Jun 29, 2009, at 4:02 PM, Lowekamp, Bradley (NIH/NLM/LHC) [C] wrote:

> Hello,
>
> I submitted an experimental build using ImageIOBase::GetPixelSize()  
> in ImageFileReader::GenderateData:
>
> http://www.cdash.org/CDash/viewTest.php?onlyfailed&buildid=367033
>
> It appears that this error is caused by some classes overloading the  
> Get methods, while others just set the internal variable. Combined  
> with the ImageIOBase inconsistently accessing these ivars with  
> either Get methods or direct access, it would appear the GetPixel  
> methods should not be made public.
>
> The previous method used by ImageFileReader to calculate the buffer  
> ImageIOBase::GetImageSizeInBytes():
> ImageIOBase::SizeType
> ImageIOBase
> ::GetImageSizeInBytes () const
> {
>   return (this->GetImageSizeInComponents() * this- 
> >GetComponentSize());
> }
>
> So perhaps it's be to just expose:
>
> ImageIOBase::GetComponentSize();
>
> and NOT expose:
>
> ImageIOBase::GetPixelSize();
>
> since the later was not used before, and the prior appears to have  
> been consistently used before.
>
> Brad
>
>
> On Jun 29, 2009, at 10:04 AM, Lowekamp, Bradley (NIH/NLM/LHC) [C]  
> wrote:
>
>> Hello,
>>
>> 	I am working on fixing the bug. In ImageFileReader I need to  
>> calculate the size of the IO buffer based on the IORegion, and I am  
>> missing some function or access to the information I need. I am  
>> proposing adding public methods to ImageIORegion and ImageIOBase:
>>
>> 1)
>>
>>   /** Get the number of pixels contained in this region. This just
>>    * multiplies the size components. */
>>   unsigned long itk::ImageIORegion::GetNumberOfPixels( void ) const;
>>
>> This methods is just copied from the ImageRegion.
>>
>> 2)
>>
>> To calculate the buffer size I need the number of pixels and the  
>> size of the pixels (or the size of the components and the number of  
>> components). Currently, the methods ImageIOBase::GetPixelStride is  
>> public, but this methods need to have ComputeStride called for it  
>> it be useful. ( I actually think this methods should still be  
>> private ). We already have GetNumberOfComponents,  
>> GetImageSizeInBytes, GetImageSizeInPixels, and
>> GetImageSizeInComponents. But no way to access the size of a pixel  
>> or component (unless you for GetImageSizeInBytes/ 
>> GetImageSizeInPixels, ick). I propose changing the following  
>> methods from protected to public:
>>
>>   /** Compute the size (in bytes) of the pixel. For
>>    * example, and RGB pixel of unsigned char would have size 3  
>> bytes. */
>>   virtual unsigned int GetPixelSize() const;
>>
>>   /** Compute the size (in bytes) of the components of a pixel. For
>>    * example, and RGB pixel of unsigned char would have a
>>    * component size of 1 byte. This method can be invoked only after
>>    * the component type is set. */
>>   virtual unsigned int GetComponentSize() const;
>>
>>
>> Thanks for your comments,
>> Brad
>>
>>
>>
>>
>>
>> ========================================================
>> 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
>
>

========================================================
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/20090702/854b83f3/attachment.htm>