Skip to content

ENH: Ingest ITKPolarTransform into Modules/Filtering#6211

Merged
dzenanz merged 59 commits intoInsightSoftwareConsortium:mainfrom
hjmjohnson:ingest-polartransform
May 7, 2026
Merged

ENH: Ingest ITKPolarTransform into Modules/Filtering#6211
dzenanz merged 59 commits intoInsightSoftwareConsortium:mainfrom
hjmjohnson:ingest-polartransform

Conversation

@hjmjohnson
Copy link
Copy Markdown
Member

Ingests ITKPolarTransform (header-only Cartesian↔polar coordinate transforms) into Modules/Filtering/PolarTransform/ using the v4 ingestion pipeline. Tier-A Wave-1 candidate from #6160. Upstream: InsightSoftwareConsortium/ITKPolarTransform at 65b3c950; will be archived after this lands.

Sanitizer report (Phase A)
sanitize-history complete:
  commits walked:        52
  prefix auto-prepended: 12
  subjects truncated:    2
  blank lines inserted:  20
  exec-bits cleared:     0
  README.rst->.md fixes: 2
  standalone-guard rm:   4
  blobs scanned:         107
  blobs reformatted:     96
  by-kind sniff:         cxx=89 py=0 cmake=15 text=2 skip=1

Final history:  82 → 50 commits, 18 → 12 merges

The new v4 sanitizer rule standalone-guard rm fired 4 times, auto-unwrapping the upstream if(NOT ITK_SOURCE_DIR) ... else() itk_module_impl() endif() standalone-build wrapper across the module's CMake history (the @dzenanz pattern from #6206). The two README.rst → .md fixes patch the upstream's file(READ "README.rst" ...) macro reference now that the in-tree README is markdown. No post-PR fixups needed for those patterns.

Topology and CI expectations
Property Value
Total PR commits 51 (47 rewritten upstream + 4 ITK-side follow-ups)
Merge commits preserved 13
Root commits 1 (unavoidable upstream root — see v4 strategy doc, "Known artifacts at PR-review time")
Branch base upstream/main @ 777a69ffab (zero commits behind at push time)

Expected CI state on push: all green except ghostflow-check-main, which fails with the single commit <sha> not allowed; it is a root commit error. That single error is documented as expected and accepted for every v4 ingest in INGESTION_STRATEGY_v4.md §"Known artifacts at PR-review time" (introduced in PR #6204).

Local verification
  • pre-commit run --all-files → exit 0
  • cmake -DModule_PolarTransform:BOOL=ON . configure clean
  • ninja PolarTransformTestDriver 47/47 build steps OK
  • ctest -R PolarTransform: 3/3 tests passed in 1.15 s
    • PolarTransformHeaderTest
    • PolarTransformInDoxygenGroup
    • itkPolarTransformTest
Phase B (post-merge) plan

Once this PR lands on main:

~/src/ITK-ingest-v4/Utilities/Maintenance/RemoteModuleIngest/archive-remote-module.sh PolarTransform

Phase B publishes the upstream-side removal commit (whitelisted files deleted, MIGRATION_README.md promoted to README.md) directly to InsightSoftwareConsortium/ITKPolarTransform's main and flips archived=true on the GitHub repo settings, per feedback_ingest_archive_readme.md.

thewtex and others added 30 commits November 14, 2017 18:15
Output of ITKModuleTemplate
Addresses:

4: WARNING: In
/home/matt/src/ITK/Modules/Core/Transform/include/itkTransform.hxx, line 40
4: Transform (0x2661eb0): Using default transform constructor.  Should specify
NOutputDims and NParameters as args to constructor.
These transforms dod not have optimizable parameters.
COMP: Unused parameters argument to SetParameters
COMP: no need to repeat virtual specifier for inherited overridden methods
COMP: explicitly overriding TransformVector at point
COMP: taking care of remaining warnings
Require CMake minimum version to be 3.9.5 following ITKv5 requiring
C++11:
https://discourse.itk.org/t/minimum-cmake-version-update/585
…umVersion

ENH: Require cmake minimum version to be 3.9.5.
Use static constexpr directly now that C++11 conformance
is required by all compilers.

:%s/itkStaticConstMacro *( *\([^,]*\),[ \_s]*\([^,]*\),\_s*\([^)]*\)) */static constexpr \2 \1 = \3/ge
== http://en.cppreference.com/w/cpp/language/type_alias ==

Type alias is a name that refers to a previously defined type (similar
to typedef).

A type alias declaration introduces a name which can be used as a
synonym for the type denoted by type-id. It does not introduce a new
type and it cannot change the meaning of an existing type name. There is
no difference between a type alias declaration and typedef declaration.
This declaration may appear in block scope, class scope, or namespace
scope.

== https://www.quora.com/Is-using-typedef-in-C++-considered-a-bad-practice ==

While typedef is still available for backward compatibility, the new
Type Alias syntax 'using Alias = ExistingLongName;' is more consistent
with the flow of C++ than the old typedef syntax 'typedef
ExistingLongName Alias;', and it also works for templates (Type alias,
alias template (since C++11)), so leftover 'typedef' aliases will differ
in style from any alias templates.
git grep -l "ITK_OVERRIDE" |   fgrep -v itk_compiler_detection.h | fgrep -v CMakeLists.txt |fgrep -v .cmake |   xargs sed -i '' -e "s/ITK_OVERRIDE/override/g"
Use constexpr for constant numeric literals.
Move `ITK_DISALLOW_COPY_AND_ASSIGN` calls to public section following
the discussion in
https://discourse.itk.org/t/noncopyable

If legacy (pre-macro) copy and assing methods existed, subsitute them
for the `ITK_DISALLOW_COPY_AND_ASSIGN` macro.
…ToPublicS

ection

COMP: Move ITK_DISALLOW_COPY_AND_ASSIGN calls to public section.
@hjmjohnson hjmjohnson force-pushed the ingest-polartransform branch from 3f67eaa to a1e147c Compare May 5, 2026 22:37
hjmjohnson added a commit to hjmjohnson/ITK that referenced this pull request May 5, 2026
Covers the three Greptile findings on PR InsightSoftwareConsortium#6211: r=0 NaN guard
(CartesianToPolar), r=0 with ConstArcIncr divide-by-zero
(PolarToCartesian), and round-trip with non-zero center in
pass-through dim.
@hjmjohnson
Copy link
Copy Markdown
Member Author

@greptileai — addressed all three findings on this PR:

Severity Finding Fixed in
P1 CartesianToPolarTransform r=0 → 0/0 NaN a41d0e4a20
P1 PolarToCartesianTransform r=0 with ConstArcIncr → divide-by-zero c61df59a3a
P2 Center offset asymmetry on pass-through dims breaks round-trip b1af9c2437

0638c5eb39 extends itkPolarTransformTest.cxx with regression cases for each.

@greptile-apps

This comment was marked as resolved.

@hjmjohnson hjmjohnson force-pushed the ingest-polartransform branch from 0638c5e to 893741c Compare May 6, 2026 13:37
@github-actions github-actions Bot removed type:Infrastructure Infrastructure/ecosystem related changes, such as CMake or buildbots area:Python wrapping Python bindings for a class type:Testing Ensure that the purpose of a class is met/the results on a wide set of test cases are correct area:Filtering Issues affecting the Filtering module area:Remotes Issues affecting the Remote module labels May 6, 2026
hjmjohnson added a commit to hjmjohnson/ITK that referenced this pull request May 6, 2026
Covers the three Greptile findings on PR InsightSoftwareConsortium#6211: r=0 NaN guard
(CartesianToPolar), r=0 with ConstArcIncr divide-by-zero
(PolarToCartesian), and round-trip with non-zero center in
pass-through dim.
hjmjohnson added 9 commits May 6, 2026 16:54
The module now lives under Modules/Filtering/PolarTransform/.  Drop
the configure-time fetch entry; consumers enable the module via
Module_PolarTransform=ON like any other in-tree module.
Now that PolarTransform is in-tree under Modules/Filtering/PolarTransform/,
exercise it on every pixi configure-ci run (Linux / macOS / Windows
GitHub Actions matrix).
In-tree, ITK's top-level CMakeLists pins the CMake minimum, so the
per-module declaration is dead code.  Matches the v4 ingest-pipeline
rule in PR InsightSoftwareConsortium#6204 (sanitize-history.py:patch_drop_cmake_minimum_required).
When inputPoint equals m_Center, vector=(0,0) so r=0, and the
unguarded vector[0]/r evaluates to 0/0 (NaN), silently propagating
through std::acos. Set alpha=0 in that branch since alpha is
undefined at r=0.
When ConstArcIncr is true and inputPoint[1] (radius) is 0, alpha /= 0
yields inf and downstream cos/sin(inf) is implementation-defined.
Short-circuit alpha=0 in that branch since the output collapses to
the center anyway.
…form

CartesianToPolarTransform leaves dims >= 2 as raw inputPoint values
(no center subtraction), but PolarToCartesianTransform was adding
m_Center to every dim including pass-through ones. The asymmetry
broke round-trip when m_Center had non-zero components in dims >= 2.
Covers the three Greptile findings on PR InsightSoftwareConsortium#6211: r=0 NaN guard
(CartesianToPolar), r=0 with ConstArcIncr divide-by-zero
(PolarToCartesian), and round-trip with non-zero center in
pass-through dim.
@hjmjohnson hjmjohnson force-pushed the ingest-polartransform branch from 893741c to 47baab7 Compare May 6, 2026 21:56
@github-actions github-actions Bot added type:Infrastructure Infrastructure/ecosystem related changes, such as CMake or buildbots area:Python wrapping Python bindings for a class type:Testing Ensure that the purpose of a class is met/the results on a wide set of test cases are correct area:Filtering Issues affecting the Filtering module area:Remotes Issues affecting the Remote module labels May 6, 2026
@hjmjohnson hjmjohnson requested a review from dzenanz May 7, 2026 11:02
@dzenanz dzenanz merged commit a44e355 into InsightSoftwareConsortium:main May 7, 2026
18 of 19 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

area:Filtering Issues affecting the Filtering module area:Python wrapping Python bindings for a class area:Remotes Issues affecting the Remote module type:Enhancement Improvement of existing methods or implementation type:Infrastructure Infrastructure/ecosystem related changes, such as CMake or buildbots type:Testing Ensure that the purpose of a class is met/the results on a wide set of test cases are correct

Projects

None yet

Development

Successfully merging this pull request may close these issues.

7 participants