-
-
Notifications
You must be signed in to change notification settings - Fork 686
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ENH: Added IndexRange for efficient region and grid space iteration #155
ENH: Added IndexRange for efficient region and grid space iteration #155
Conversation
This pull request is intended to supersede PR #106 from @hjmjohnson his Gerrit migration fork! |
I hope 🙏 that this one has SFINAE implemented correctly 😓 |
SFINAE still not entirely correct. My bad! Should have read more carefully! https://stackoverflow.com/questions/46603353/sfinae-on-constructors-works-in-vc2017-but-not-in-clang-gcc Will try another fix! |
Update: the compilers appear to accept the patch now, including SFINAE, but KWSyle still complains:
I guess I should just add a dummy template parameter, to please KWSyle. |
Please add an override statement for in the ITKKWStyleOverwrite.txt instead. |
* case there is a substitution failure, and C++ "SFINAE" kicks in). | ||
*/ | ||
template <bool VIsSubstitutionFailure = VBeginAtZero, | ||
typename TVoid = typename std::enable_if<!VIsSubstitutionFailure>::type> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry @hjmjohnson I read your suggestion to modify "ITKKWStyleOverwrite.txt" too late. Already added a 'dummy' template parameter (TVoid
). Which is not so bad anyway, as it documents the expected type (void
) for this template argument: std::enable_if<!VIsSubstitutionFailure>::type
should yield void
, if anything at all.
Added Experimental::IndexRange, to allow efficient iteration over the indices of an image region or grid space by means of a C++11 range-based for-loop or Standard C++ algorithm. Added type aliases, ImageRegionIndexRange<Dimension> and ZeroBasedIndexRange<Dimension>. This class appears useful in combination with ShapedImageNeighborhoodRange, e.g.: ImageRegionIndexRange<Dimension> indexRange{ imageRegion }; for (IndexType index : indexRange) { shapedImageNeighborhoodRange.SetLocation(index); for (PixelType neighborPixel : shapedImageNeighborhoodRange) // Process neighbor pixel... } Change-Id: Ia1f777ba251a9c617f55c16bf37878eaee632f43
using ImageRegionIndexRange = IndexRange<VDimension, false>; | ||
|
||
template<unsigned VDimension> | ||
using ZeroBasedIndexRange = IndexRange<VDimension, true>; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Update: the latest amend has an extra type alias, ZeroBasedIndexRange<Dimension>
, optimized for zero-based index iteration.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sweet! 🍬
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is extremely exciting @N-Dekker; for the C++ API, for the performance, and for the potential C++11 parallel STL algorithm applications! Awesome. 🏆
The implementation looks great, building on everything learned from ShapedImageNeighborhoodRange
, zero-index optimization 👌, and well tested 🥇 .
For the naming 😇 , I am wondering if ImageRegionRange
would be clearer for someone new to the toolkit? While we live in ITK all the time and think itk::Index
when we see index
, the "normal" C++ developers will likely think this is a array container linear index at first glance. What do you think?
@thewtex Thanks for you kind words and the accompanied emoticons :-) I do agree that it might not be directly clear to every new ITK user that the index of Also I think it's an important property of this class that it only yields index values (and not pixel values). So I would prefer to keep the term Index in there. Hope my reasoning makes sense to you :-) |
I agree with @N-Dekker here. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍
@N-Dekker A few warnings on the dashboard showed up after this: |
@hjmjohnson wrote:
Thanks Hans, I think I can fix them easily (Linux-x86_64-gcc4.8-m32: "declaration of 'size' shadows a member" and "missing initializer for member"). Do you know why these warnings did not appear before? At least I did not see them at the commit https://github.com/InsightSoftwareConsortium/ITK/pull/155/commits or at the Linux build results from Azure https://dev.azure.com/itkrobotlinux/ITK.Linux/_build/results?buildId=194&view=logs |
FYI: https://open.cdash.org/viewBuildError.php?type=1&buildid=5629918 Modules/Core/Common/include/itkIndexRange.h:302:46: warning: missing initializer for member 'itk::Index<1u>::m_InternalArray' [-Wmissing-field-initializers] |
Added
Experimental::IndexRange
, to allow efficient iteration overthe indices of an image region or grid space by means of a C++11
range-based for-loop or Standard C++ algorithm. Added type aliases,
ImageRegionIndexRange<Dimension>
andZeroBasedIndexRange<Dimension>
.This class appears useful in combination with ShapedImageNeighborhoodRange, e.g.: