<table cellspacing="0" cellpadding="0" border="0" ><tr><td valign="top" style="font: inherit;"><div><ul><li>1) If I'm going to do this type of thing:</li><li><br></li><li> IteratorType::OffsetType top = {{0,-1}};</li><li> IteratorType::OffsetType bottom = {{0,1}};</li><li> IteratorType::OffsetType left = {{-1,0}};</li><li> IteratorType::OffsetType right = {{1,0}};</li><li><br></li><li>Then get the pixels with:</li><li>iterator[top][0]</li><li><br></li><li>is there an advantage to using the ShapedNeighborhoodIterator over just a NeighborhoodIterator?</li></ul><div><hr></div></div><div><br></div><div>You can use offsets for both ShapedNeighborhoodIterator and regular </div><div><br></div><div>NeighborhoodIterator, the difference is in performance. A regular </div><div><br></div><div>NeighborhoodIterator would need more pixels to form a rectangular </div><div><br></div><div>neighborhood
(which artificially could be considered as a </div><div><br></div><div>"ShapedNeighborhoodIterator" using offsets) but a </div><div><br></div><div>ShapedNeighborhoodIterator would require less pixels in the neighborhood</div><div><br></div><div>to form a shaped neighborhood, less pixels mean less memory allocation</div><div><br></div><div>and less boundary checking which could remarkably improve the performance</div><div><br></div><div>specially for large neighborhoods in large and multidimensional images plus,</div><div><br></div><div>handling shaped neighborhoods is easier with the ShapedNeighborhoodIterator.</div><div><br></div><div><hr></div><div><br></div><div><div class="yiv1493217550gmail_quote"><div><ul><li>2) If I do want to use the ShapedNeighborhood style, is this correct:</li><li><br></li><li>IteratorType::IndexListType::const_iterator indexIterator =
iterator.GetActiveIndexList().begin();</li><li> while (indexIterator != iterator.GetActiveIndexList().end())</li><li> {</li><li> std::cout << (int)iterator[*indexIterator][0] << " ";</li><li> ++indexIterator;</li><li> }</li></ul><div><br></div><div><hr>Yes, the following is also a good practice:</div><div><br></div><div><div>IteratorType::ConstIterator ci;</div><div><br></div><div><span class="Apple-tab-span" style="white-space:pre"> </span> for (ci = iterator.Begin(); ci != iterator.End(); ci++)</div><div><br></div><div><span class="Apple-tab-span" style="white-space:pre"> </span> { </div><div><br></div><div> std::cout << ci.get() << std::endl;</div><div><br></div><div>
}</div><div><br></div><div><hr><br></div></div></div><div><ul><li>3) If I loop over the ActiveIndexList using the FaceCalculator, is the idea that in all regions except the 0th region I need to do something like:</li><li><br></li><li>IteratorType::IndexListType::const_iterator indexIterator = iterator.GetActiveIndexList().begin();</li><li> while (indexIterator != iterator.GetActiveIndexList().end())</li><li> {</li><li> bool valid;</li><li> iterator.GetPixel(*indexIterator,valid);</li><li> if(valid) { do something }</li><li> ++indexIterator;</li><li> }</li><li><br></li><li>Alternatively, I could use 4 separate loops (one for each face region) where I know which neighbor isn't valid. I would have to modify the ActiveIndexList to reflect this missing pixel before each
loop.</li></ul><div><hr><br></div><div>Usually for neither of face calculator or neighborhood iterator you need to perform </div><div><br></div><div>the boundary check yourself (notice that the iterator itself has to iterate over the </div><div><br></div><div>boundary to check for its validity), the face calculator splits the image into boundary </div><div><br></div><div>and non-boundary regions for the iterator to not to check for all of the pixels and </div><div><br></div><div>only perform the boundary checking for pixels in the face region (pixels with distance </div><div><br></div><div>from the image boundary equal or less than the neighborhood radius). This would also</div><div><br></div><div> improve the performance specially for large datasets.</div><div><br></div><div><hr></div></div><div><ul><li>4) I believe </li><li>iterator[top][0]</li><li>is equivalent to but faster than iterator.GetPixel(top). Is
this correct?</li></ul></div><div><hr>I'm not sure about this since I haven't seen a significant performance difference.</div><div><br></div><div><ul><li><hr></li><li>5) Am I correct that the face calculator returns overlapping regions? If I use a 5x5 image with a 3x3 kernel, it returns regions of size</li><li>9</li><li>5</li><li>5</li><li>5</li><li>5</li><li><br></li><li>totaling 29, when there are only 25 pixels. I don't see any functions to turn on/off this overlap. How is this usually handled?</li></ul><div><hr><br></div><div>To the best of my knowledge this is still an unsolved issue which was brought up </div><div><br></div><div>by other users in the list as well. Usually the face calculator assumes that the </div><div><br></div><div>face region is far smaller than the non-boundary region which could be an issue </div><div><br></div><div>for small images or very large
neighborhoods.</div><div><br></div><div><br></div><div>Regards,</div><div><br></div><div>Dawood</div></div></div></div></td></tr></table><br>