[ITK Community] Bug in DefaultVectorPixelAccessor

[Bradley Lowekamp]

Hello,

You are right that the GetPixel methods are slow, but that's why iterators are recommended.

Currently you are trying to have you "if( featureImage2 )" in side the per-pixel loop. Not only does this cause you iterator initialization issue it also is slower of have this if statement inside the loop.

Here is an alternative way to construct your logic:

https://github.com/InsightSoftwareConsortium/ITK/blob/master/Modules/Filtering/ImageFilterBase/include/itkBinaryFunctorImageFilter.hxx#L224-L297

Hope this help,
Brad

On Mar 11, 2014, at 8:34 AM, Jan Ehrhardt <ehrhardt at imi.uni-luebeck.de> wrote:

> Hi Matt,
> 
> yes, I currently use the ITK iterators, but I have the following problem. 
> 
> Standard code looks like:
> 
> itk::ImageRegionIterator<ImageType1> it( radius, myImage, region );
> itk::ImageRegionIterator<ImageType2> featureIt1( radius, featureImage1, region );
> itk::ImageRegionIterator<ImageType3> featureIt2( radius, featureImage2, region );
> 
> it.GotoBegin();
> featureIt1.GotoBegin();
> featureIt2.GotoBegin();
> 
> while(!it.IsAtEnd())
> {
>    // do some complicated processing stuff with or without feature1 and/or feature2
> 
>   ++it;
>   ++featureIt1;
>   ++featureIt2;
> }
> 
> I only know at runtime, whether featureImage1 and/or featureImage2 are available. If
> featureImage1 or featureImage2 is NULL, a segmentation fault occurs.
> 
> Therefore, I have currently implemented:
> 
> itk::ConstNeighborhoodIterator<ImageType1> it( radius, myImage, region );
> 
> it.GotoBegin();
> 
> while(!it.IsAtEnd())
> {
>    currentIndex=it.GetIndex();
>    if( featureImage1.IsNotNull())
>    {
>         // use featureImage1->GetPixel(currentIndex) to process feature 1
>     }
>     if( featureImage2.IsNotNull())
>    {
>         // use featureImage2->GetPixel(currentIndex) to process feature 2
>    }
>    
>    // do some other stuff
> 
>   ++it;
> }
> 
> The Image::GetPixel() method is quite time-consuming and therefore I look for a more efficient method
> to implement this code (without writing four different versions).
> 
> Any suggestions?
> 
> Best regards,
> Jan
> 
> On 03/11/2014 06:12 AM, Matt McCormick wrote:
>> Hi Jan,
>> 
>> To iterator through an Image or VectorImage, use the Iterators as described in the Software Guide [1]
>> 
>> HTH,
>> Matt
>> 
>> [1] http://itk.org/ItkSoftwareGuide.pdf
>> 
>> 
>> On Thu, Mar 6, 2014 at 8:23 AM, Jan Ehrhardt <ehrhardt at imi.uni-luebeck.de> wrote:
>> Hi folks,
>> 
>> I want to iterate through a vector image without an iterator. My approach was:
>> 
>>     MultiChannelImageType::AccessorType accessor = pImage->GetPixelAccessor();
>>     MultiChannelImageType::InternalPixelType* pBuffer = pImage->GetBufferPointer();
>> 
>>     for( OffsetValueType i = from; i < to; ++i )
>>     {
>>         vecPixel = accessor.Get(*pBuffer, i);
>>     }
>> 
>> but the results are not correct (see bug(?) below). If the bug(?) in DefaultVectorPixelAccessor is corrected ( m_OffsetMultiplier = l ) the behaviour of standard itk iterators change. I assume, I don't understand the parameters of DefaultVectorPixelAccessor::Get() correctly.
>> How can I use the DefaultVectorPixelAccessor correctly?
>> 
>> best,
>> jan
>> 
>> 
>> On 03/06/2014 12:25 PM, Jan Ehrhardt wrote:
>> Hi folks,
>> 
>> there is a bug in DefaultVectorPixelAccessor (ITK 4.4.0):
>> 
>>   void SetVectorLength(VectorLengthType l)
>>   {
>>     m_VectorLength = l;
>>     m_OffsetMultiplier = ( l - 1 );
>>   }
>> 
>>   DefaultVectorPixelAccessor(VectorLengthType l)
>>   {
>>     m_VectorLength = l;
>>     m_OffsetMultiplier = l - 1;
>>   }
>> 
>> OffsetMultiplier should be m_OffsetMultiplier = l;
>> 
>> Best regards,
>> Jan
>> 
>> 
>> _______________________________________________
>> Community mailing list
>> Community at itk.org
>> http://public.kitware.com/cgi-bin/mailman/listinfo/community
>> 
> 
> _______________________________________________
> Community mailing list
> Community at itk.org
> http://public.kitware.com/cgi-bin/mailman/listinfo/community

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/community/attachments/20140311/88fc4ac4/attachment-0002.html>