-
-
Notifications
You must be signed in to change notification settings - Fork 682
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
Add AnatomicalOrientation class #4804
Add AnatomicalOrientation class #4804
Conversation
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.
Looks good so far!
This comment was marked as off-topic.
This comment was marked as off-topic.
2502620
to
fb83a56
Compare
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
Please move this conversation about MINC to #147 or another place on topic. |
fb83a56
to
4042eb3
Compare
4042eb3
to
3e2ef5b
Compare
@dzenanz Almost there. There is currently both the ToEnum, and FromEnum. The class "AnatomicalOrientation" can be seen to hold the representation of the orientation, and provide conversion with the Enum's, direction matrix, and perhaps the preferred handling it as 3 components. There is still the ToEnum string representation left over from the original DICOMOrientation class. That is |
I would like to have this. This convenience did not exist within ITK proper before, so there is no need for some sort of backwards compatibility. I wonder whether we should have a method to convert "To" string from a "From" string and vice versa. E.g. if an application has "RAI" string as a "From" code, it can call something like |
So your suggestion is to keep the ambiguous "ToEnum" character representation, and just add a method to convert To/From character representations? The concern here is really when |
If you want, you can remove the string constructor. Is there another similarly convenient way to initialize it? Something like: auto identityAO = AnatomicalOrientation::ToEnum("LPS");
AnatomicalOrientation ao(identityAO); |
More generally,: std::string toCode = "LPS";
auto aoEnum = AnatomicalOrientation::ToEnum(toCode);
AnatomicalOrientation ao(aoEnum); |
What is the status of this PR? I would like it to be finished/merged before it becomes stale, as PR revival usually involves extra effort. |
3e2ef5b
to
62a566b
Compare
@dzenanz Shall we have the SpatialOrientation filter changes be in another PR? |
I am fine with that. And that might even be better, to not hold up this PR. |
62a566b
to
7192104
Compare
b642f96
to
58576c4
Compare
58576c4
to
ded6b69
Compare
ded6b69
to
1fb80ea
Compare
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.
🍾
I'm planning on merging this tomorrow unless there are further comments. |
@blowekamp Shall I still have a look before the merge? |
yes please. |
AnatomicalOrientation::PositiveEnum | ||
AnatomicalOrientation::ConvertDirectionToPositiveEnum(const DirectionType & dir) | ||
{ | ||
// NOTE: This method was based off of itk::SpatialObjectAdaptor::FromDirectionCosines | ||
// but it is DIFFERENT in the meaning of direction in terms of sign-ness. | ||
CoordinateEnum terms[3] = { CoordinateEnum::UNKNOWN, CoordinateEnum::UNKNOWN, CoordinateEnum::UNKNOWN }; | ||
|
||
std::multimap<double, std::pair<unsigned, unsigned>> value_to_idx; | ||
for (unsigned int c = 0; c < 3; ++c) | ||
{ | ||
for (unsigned int r = 0; r < 3; ++r) | ||
{ | ||
value_to_idx.emplace(std::abs(dir[c][r]), std::make_pair(c, r)); | ||
} | ||
} |
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.
ConvertDirectionToPositiveEnum
is hard for me to understand. I hope the other reviewers do understand it better than I do 😃
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.
The math or the general input and output of the method?
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.
So you are creating this multi-map, in order to find the direction matrix element that has the highest absolute value, right? (Just for my understanding -- this is not a change request.)
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.
Yes, that appears to be what is going on. As the comment says it was mostly a copy of the existing working method in itk::SpatialObjectAdaptor::FromDirectionCosines
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.
OK, thanks, and the math itself? How does it work? Is it a known approach?
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.
It is a tested algorithm that worked for all the test cases I put it through. It explicitly does what a "smarter" and incorrect algorithm did previously:
8801247
🎆 🎊 🥳 |
@blowekamp There appear some compile errors at the CI (master branch), if you know how to fix them, please do 😃 At https://open.cdash.org/viewBuildError.php?buildid=9981860
|
Follow up: #4899 |
Seems like there's a warning in the
Visible in the dashboard as well: Not sure how the below block could be handled better to avoid the warning: |
Neither am I. Is the build/wrapping defining ITK_LEGACY_SILENT when compiling? |
@blowekamp Please note that the warning still uses the term |
Yes, good catch the text in the warning should be updated as you recommend. But the issue is that the warning should not be occurring. |
Perhaps the bigger problem on the nightly build:
@seanm may be compiling with LEGACY_REMOVE enabled so this conversion function is removed. |
Most of |
But they don't have PhilipsREC module enabled? |
Ah, that is a non-default module, which I indeed did not turn on. |
This PR is a WIP, and more details will be added here when ready for discussion and review.
See #4788 for this issue and discussion of these changes.