Add AnatomicalOrientation class

[blowekamp]

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.

[dzenanz]

Looks good so far!

[blowekamp]

Please move this conversation about MINC to #147 or another place on topic.

[blowekamp]

@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 AnatomicalOreination("LPS") construction and AnatomicalOrientation(OE::LPS).ToString() == "LPS". Anatomicalorientation::operator<< produce something like "left-to-right, anterior-to-posterior, inferior-to-superior" now, which is unambiguous. Perhaps the string character tripplets should just be removed? However the string representation is convent with a Python interface.

[dzenanz]

AnatomicalOreination("LPS") construction and AnatomicalOrientation(OE::LPS).ToString() == "LPS"

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 AnatomicalOrientation::ConvertToFrom("RAI") and get "LPS". Such method would be symmetric, as the same operation would be needed to go from "From" to "To", and from "To" to "From" convention.

[blowekamp]

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 AnatomicalOrientation("RIA") would be used, it is not clear if the string is being interpreted as a ToEnum or a FromEnum.

[dzenanz]

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);

[dzenanz]

More generally,:

std::string toCode = "LPS";
auto aoEnum = AnatomicalOrientation::ToEnum(toCode);
AnatomicalOrientation ao(aoEnum);

[dzenanz]

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.

[blowekamp]

@dzenanz Shall we have the SpatialOrientation filter changes be in another PR?

[dzenanz]

I am fine with that. And that might even be better, to not hold up this PR.

[blowekamp]

When Legacy Remove is enabled deprecated warnings are generated causing one of the ITK Linux builds to failed. What is the expected behavior here?

Addendum: Added ITK_LEGACY_SILENT support.

[blowekamp]

Current warning is due to testing of the deprecated methods:

2024-09-05T14:28:44.5388532Z /home/vsts/work/1/s/Modules/Core/Common/test/itkAnatomicalOrientationGTest.cxx:244:73: warning: 'itk::AnatomicalOrientation::AnatomicalOrientation(itk::AnatomicalOrientation::LegacyOrientationType)' is deprecated: Use the AnatomicalOrientation::FromEnum type instead. [-Wdeprecated-declarations]
2024-09-05T14:28:44.5389330Z   244 |   itk::AnatomicalOrientation itk_rai(SOE::ITK_COORDINATE_ORIENTATION_RAI);
2024-09-05T14:28:44.5389692Z       |                                                                         ^
2024-09-05T14:28:44.5390384Z In file included from /home/vsts/work/1/s/Modules/Core/Common/test/itkAnatomicalOrientationGTest.cxx:22:
2024-09-05T14:28:44.5390862Z /home/vsts/work/1/s/Modules/Core/Common/include/itkAnatomicalOrientation.h:424:3: note: declared here
2024-09-05T14:28:44.5391276Z   424 |   AnatomicalOrientation(LegacyOrientationType legacyOrientation);

Anyone know other locations in ITK which test deprecated methods with out warnings?

[dzenanz]

This might be the answer you are looking for:

ITK/Modules/Core/Common/test/itkSTLThreadTest.cxx

Lines 18 to 20 in fb61d2c

	#ifndef ITK_LEGACY_REMOVE
	# define ITK_LEGACY_TEST // so deprecation warnings are not triggered by this test
	#endif

[dzenanz]

Taking a look at the definition in itkMacro.h, it might not.

[dzenanz]

This is primarily rebase and squash? With removal of #ifdef ITK_AMBIGUOUS_TO_COORDINATE_ENUMS?

[blowekamp]

This is primarily rebase and squash? With removal of #ifdef ITK_AMBIGUOUS_TO_COORDINATE_ENUMS?

Yes

[dzenanz]

Mark as "ready for review"?

[blowekamp]

The Documentation still needs work.

[thewtex]

Very nice!!

Inline comment regarding method naming.

Wish list, could come later: *Long* methods to work with the names as used in PrintSelf.

[blowekamp]

These following methods have asymmetry with regards to the currently names "ToEnum" and "FromEnum".

Perhaps the following would be consistent with the other "CreateFrom..Enum" methods:

static AnatomicalOrientation CreateFromDirectionCosines( const DirectionType &)

[blowekamp]

Wish list, could come later: *Long* methods to work with the names as used in PrintSelf.

The class has an "operator<<" so it work sells as a ivar for ITK classes derived from LightObject with a PrintSelf methods. Could you please explain this further or be more specific.

[thewtex]

The class has an "operator<<" so it work sells as a ivar for ITK classes derived from LightObject with a PrintSelf methods.

Yes, that is nice.

Could you please explain this further or be more specific.

I was thinking:

  static const std::map<PositiveEnum, std::string> &
  GetCodeToLongString();
// returns "left-to-right", for example

  static const std::map<std::string, PositiveEnum> &
  GetLongStringToCode()
// has "left-to-right", etc. keys