[Insight-developers] fast image pixel access method

Kris Zygmunt krismz at sci.utah.edu
Mon May 13 15:12:13 EDT 2013


If you were going to take Brad's approach with generating the list of  
sample points once, you could try using the Subsamplers in Numerics/ 
Statistics to do the subsampling and then use the sorts available in  
itkStatisticsAlgorithm.  You could start with  
itkUniformRandomSpatialNeighborSubsampler to choose samples within a  
specified region of the image (see the corresponding test for an  
example).  In this approach, each sample is already a  
NeighborhoodIterator.  As Brad pointed out, it depends on what you're  
doing for this overhead to be useful, but I'd be curious to see how  
the timing works out and compars to what you've done already.

I'm not sure whether this will be useful for you, but I mention it in  
case others are looking for ways to sample the images.
-Kris

> Date: Mon, 13 May 2013 11:59:23 -0400
> From: Bradley Lowekamp <blowekamp at mail.nih.gov>
> Subject: Re: [Insight-developers] fast image pixel access method
> To: <gaoyi.cn at gmail.com>
> Cc: "Insight-developers at itk.org" <Insight-developers at itk.org>,
> 	"Williams,	Norman K" <norman-k-williams at uiowa.edu>
> Message-ID: <8EF7C1BA-41CE-4F5D-B7AA-9F186F70FCE5 at mail.nih.gov>
> Content-Type: text/plain; charset="iso-8859-1"
>
> One more thought.
>
> If you are generating the list of sample points once and then using  
> them multiple times to sample there are perhaps other interesting  
> things which could be done.
>
> CPU likes to access memory in a linear fashion. Depending on your  
> density, and the size of the neighborhood etc.. If you access your  
> random points in a sequential fashion you may see benefits. That is  
> 1) generate a sequential set of random points 2) sample the points  
> in order. Step 2 should may see some benefits... Now under what  
> conditions does it out weight the first?
>
> Brad
>
> On May 13, 2013, at 11:49 AM, "Gao, Yi" <gaoyi.cn at gmail.com> wrote:
>
>> Hi Brad,
>>
>> Thank you for the suggestion!
>>
>> Sorry in my previous code I had the mistake for randomly picking  
>> position for the center point. Now I changed it to be in the inner  
>> region.
>> index[0] = rg.lrand32(1, size[0] - 2);
>> index[1] = rg.lrand32(1, size[1] - 2);
>> index[2] = rg.lrand32(1, size[2] - 2);
>>
>> And I also turn off the boundary condition by:
>> it.NeedToUseBoundaryConditionOff();
>>
>> Now with the same parameters, nbhditerator is around 4 seconds (vs  
>> direct access 5.5 seconds)!
>>
>> I will modify my code to take advantage of this!
>>
>> Thank you!
>>
>> Best,
>> yi
>>
>>
>>
>> On Mon, May 13, 2013 at 11:34 AM, Bradley Lowekamp <blowekamp at mail.nih.gov 
>> > wrote:
>> Hello,
>>
>> On May 13, 2013, at 11:03 AM, "Gao, Yi" <gaoyi.cn at gmail.com> wrote:
>>> When using NeighborhoodIterator, i'm not sure if the boundary  
>>> checking is automatically turned on. I guess if that is by default  
>>> on, then there is not much speed gain with it.
>>
>>
>> Because the region you specify to the Iterator is on the boundary  
>> it will turn on the boundary checking. You can either turn off the  
>> condition:
>>
>> http://www.itk.org/Doxygen/html/classitk_1_1ConstNeighborhoodIterator.html#a438cb0146b802b04a771a2461952cff8
>>
>> or you can change the region size you initialize the Iterator with.
>>
>> You can just use the operator<< to check what the iterator is doing.
>>
>> Also consider using a large type for the accumulation type, such as  
>> itk::NumericTraits<T>::AccumulatorType;
>>
>> And consider using std::accumulate(it.Begin(), it.End(), 0 )
>>
>> Brad
>>
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://www.itk.org/pipermail/insight-developers/attachments/20130513/8b26666b/attachment-0001.htm 
> >
>
> ------------------------------
>
> _______________________________________________
> Insight-developers mailing list
> Insight-developers at itk.org
> http://www.itk.org/mailman/listinfo/insight-developers
>
>
> End of Insight-developers Digest, Vol 109, Issue 13
> ***************************************************



More information about the Insight-developers mailing list