ENH: Master tracking — Remote-module ingestion, archival, and consolidation #6160

Activity

1. hjmjohnson commented on Apr 28, 2026

   

   hjmjohnson

   on Apr 28, 2026

   MemberAuthor

   More actions

   Wave-1 progress: MeshNoise ingest in flight as #6161. Closes #5174 in the same PR.
2. hjmjohnson commented on Apr 28, 2026

   

   hjmjohnson

   on Apr 28, 2026

   MemberAuthor

   More actions

   Phase-0 infrastructure follow-up: #6162 deprecates normalize-ingest-commits.py (which linearized history on PRs #6135, #6137, #6159, #6161) and adds rewrite-history-merge-preserving.py, the merge-preserving replacement implementing the Phase 1 / Phase 2 / Phase 3 / Phase 4 architecture from ~/.claude/rules/ingest-merge-topology.md.
3. hjmjohnson

   self-assigned this

   on Apr 29, 2026
4. hjmjohnson

   added a commit that references this issue on Apr 30, 2026

   DOC: Promote migration notice to README.md so GitHub landing page sho…

   ...

   71ef035
5. hjmjohnson commented on Apr 30, 2026

   

   hjmjohnson

   on Apr 30, 2026

   MemberAuthor

   More actions

   LabelErodeDilate ingest merged as #6171 (upstream 690015cae2); standalone repo InsightSoftwareConsortium/ITKLabelErodeDilate README replaced with migration notice (commit 71ef035) and repo archived ✓.
6. hjmjohnson commented on May 4, 2026

   

   hjmjohnson

   on May 4, 2026

   MemberAuthor

   More actions

   Decision: archive AnalyzeObjectLabelMap without ingesting

   Tracked in #6160. Local commit on branch hjmjohnson/archive-AnalyzeObjectLabelMap removes Modules/Remote/AnalyzeObjectLabelMap.remote.cmake.

   Rationale

   The Analyze Object Map .obj format is a legacy format from the late 1990s / early 2000s era of Mayo Clinic's Analyze software. The ITKAnalyzeObjectMap module is essentially the only open-source reader/writer for it. There is a small residual user base of Analyze software (AnalyzeDirect reports about 3 employees and the software is still commercially sold), but those users work within the commercial Analyze environment and are unlikely to need the ITK reader. No other major open-source imaging package — Slicer, SPM, FreeSurfer, FSL, AFNI — supports the format.

   The remote module has been maintained at minimum level — CI builds pass, it was updated for ITK 5.x API changes — but it has zero stars, no releases, and the underlying format has been superseded. Unless someone at a specific institution has legacy Analyze Object Map data they need to convert, this module is effectively dormant.

   Recommended path for any remaining users

   Users with legacy Analyze Object Map data should perform a one-time conversion to NIfTI label maps (well-supported across the open-source imaging ecosystem) and move forward without needing the ITK reader.

   Effect of this archival

   • Modules/Remote/AnalyzeObjectLabelMap.remote.cmake is removed; the module is no longer reachable via -DModule_AnalyzeObjectLabelMap:BOOL=ON in ITK builds.
   • Upstream repository InsightSoftwareConsortium/ITKAnalyzeObjectMap remains read-accessible for anyone needing the historical reader; it should be flipped to archived=true after the ITK PR merges (no Phase B ingestion-archival run is needed since nothing was ingested into ITK proper).

   👍React with 👍1Reacted by Dženan Zukić
7. hjmjohnson commented on May 5, 2026

   

   hjmjohnson

   on May 5, 2026

   MemberAuthor

   More actions

   In-flight PR snapshot (2026-05-05).

   PR	State	Module / scope	Notes
   #6205	✅ merged	Cuberille → Modules/Filtering/	First v4-strategy ingest; surfaced the deny-pass + commit-prefix-cap fixes that #6204 then encoded
   #6206	open, ready-for-review	IOMeshSTL → Modules/IO/	Greptile P1+P2 addressed (fffd214a → rebased, now f100c257); @dzenanz feedback addressed (if(NOT ITK_SOURCE_DIR) wrapper dropped, .ExternalData_MD5_<hash> cache files removed); rebased onto current upstream/main with --rebase-merges (25 merges + 1 root unchanged); only ghostflow root-commit error remains (acknowledged-unavoidable)
   #6208	open, ready-for-review	RLEImage → Modules/Filtering/	Greptile P1+P2 addressed (3 fixed, 1 push-back with local-test evidence); 6/6 RLEImage tests pass locally; prerequisite for #6209 because MCI's tests use itk::RLEImage
   #6209	🔒 closed (queue-management)	MorphologicalContourInterpolation → Modules/Filtering/	Closed pending #6208 merge. ExternalData side-work landed independently: 11 missing CIDs published via ITKTestingData#47 (merged 2026-05-05), Populate shared ExternalData cache rerun went green (ok=2457 fail=0). Branch preserved on hjmjohnson:ingest-mci; resubmit once #6208 lands
   #6204	open, draft	v4 ingestion strategy (INGESTION_STRATEGY_v4.md, ingest-module-v4.sh, sanitize-history.py, archive-remote-module.sh)	Added today: ghostflow root-commit + Greptile pattern documentation; auto-strip of **/.ExternalData_*; auto-unwrap of if(NOT ITK_SOURCE_DIR) standalone-build CMake guard. v4 supersedes the deprecated normalize-ingest-commits.py referenced in #6162

   Merge order and dependencies

   #6204 (v4 strategy)        independent — merge anytime
   #6206 (IOMeshSTL)          independent — ready to merge
   #6208 (RLEImage)           independent — ready to merge   ──┐
                                                               ▼
   #6209 (MCI, closed)        will reopen after #6208 merges (MCI tests use itk::RLEImage)
   

   Cuberille (#6205, merged) and the v4 strategy refinements landed on #6204 today close the loop on v4's first iteration: deny-pass globs and CMake standalone-build-guard unwrap are now part of Phase A, so future ingests should not need post-PR fixups for those two patterns.

   Tier-A queue items unblocked once #6208 / #6206 merge

   After #6206 (IOMeshSTL) and #6208 (RLEImage) land:

   • ⭐ MorphologicalContourInterpolation — re-submit ENH: Ingest ITKMorphologicalContourInterpolation (stacked on #6208) #6209 (already prepared)
   • SplitComponents, SubdivisionQuadEdgeMeshFilter, ParabolicMorphology, SmoothingRecursiveYvvGaussianFilter, IOMeshMZ3, IOFDF, HigherOrderAccurateGradient, PolarTransform, MultipleImageIterator — all Wave-1 candidates with v4 strategy now hardened against the patterns surfaced by Cuberille / IOMeshSTL / RLEImage
8. hjmjohnson

   added a commit that references this issue on May 5, 2026

   COMP: Drop AnalyzeObjectLabelMap remote module (deprecated, not inges…

   ...

   9a8b40e
9. thewtex commented on May 6, 2026

   

   thewtex

   on May 6, 2026

   Last edited by thewtex

   Member

   More actions

   @hjmjohnson absolutely incredible work!!! 🥇 💖 🎇 ✨

   ---

   Per #6060 (comment)

   If a module depends on itk-filtering, I'm pretty sure #6093 will increase the loading time.

   There is a real issue with module size, module dependencies, that is a major concern for loading / performance.

   ---

   itk-filtering, itk-io, etc. are groups of module packaged into wheels. itk-filtering, itk-io modules depend on itk-core modules, but not other module group wheels. We do want to keep this separation.

   ---

   Note that all modules in one wheel group, e.g. itk-filtering, do not necessarily all load at once. However a module is installed, a module will only load itself, its module dependencies, and its module transitive dependencies.

   ---

   A practical issue with the integration of more classes into the module wheels is that we are almost at the wheel size limit (100MB) for multiple wheel groups, e.g. itk-filtering, itk-numerics:

   • https://pypi.org/project/itk-numerics/#files
   • https://pypi.org/project/itk-filtering/#files

   We will need more mostly independent wheel groups for distribution.

   It might be not "significant" for one module but it will become significant as the number of integrated remote modules increases. And my point is it's already too long and we should consider splitting in more packages to benefit more from the lazy loading.

   Yes. The issue here is more that modules are not isolated enough in the dependency graph. And some are tool large.

   ---

   In the plan above, I think we need a Phase 4B and Phase 4C.

   Phase 4B: Improve module dependency graph

   1. Create an improved module organization based on a.) semantics, b.) functionality, c.) class depedencies
   2. Module size
   3. Isolated branches

   Likely an NP-hard problem, but an LLM may be able to propose a variety of module names, then write some scripts to experimently / greedly try placing modules in graphs.

   Phase 4C: Sort the modules into wheel groups

   Similar criteria. We should target the packaged wheels to be < 50 MB.

   CC @hjmjohnson @SimonRit @dzenanz @blowekamp
10. dzenanz commented on May 6, 2026

    

    dzenanz

    on May 6, 2026

    Member

    More actions

    One idea: put all the modules that are not built by default into an -optional wheel, e.g. itk-filtering-optional.

    How much FEM (if anything) contributes to the size of itk-numerics wheel? I have never heard of ITK's FEM framework being used. Maybe now is a good time to deprecate it?
11. SimonRit commented on May 6, 2026

    

    SimonRit

    on May 6, 2026

    More actions

    I tried to look at the dependency graph in my regular ITK build with this patch

    diff --git a/CMake/ITKModuleEnablement.cmake b/CMake/ITKModuleEnablement.cmake
    index 218187f33f..7abdcc2be8 100644
    --- a/CMake/ITKModuleEnablement.cmake
    +++ b/CMake/ITKModuleEnablement.cmake
    @@ -98,6 +98,10 @@ macro(itk_module_check itk-module _needed_by stack)
         endforeach()
         set(check_finished_${itk-module} 1)
       endif()
    +  file(APPEND ${CMAKE_BINARY_DIR}/graph "${itk-module} [label=\"${itk-module}\"]\n")
    +  foreach(dep IN LISTS ITK_MODULE_${itk-module}_DEPENDS)
    +      file(APPEND ${CMAKE_BINARY_DIR}/graph "${itk-module} -> ${dep}\n")
    +  endforeach()
     endmacro()
     
     set(ModuleEnablementNeedsToRerun ON) # this needs to run at least once
    

    and, I'm not sure it's helpful but you can have a look (for an ITK configured with default modules and RTK I believe):
    https://www.creatis.insa-lyon.fr/~srit/itk_dependency_graph.dot
    https://www.creatis.insa-lyon.fr/~srit/itk_dependency_graph.svg

    👍React with 👍2Reacted by Dženan Zukić and Matt McCormick

    😕React with 😕1Reacted by Matt McCormick
12. hjmjohnson commented on May 7, 2026

    

    hjmjohnson

    on May 7, 2026

    MemberAuthor

    More actions

    Status update — 2026-05-07

    Seven additional Wave 1 ingests have landed since the last update:

    PR	Module	Group
    —	Cuberille	Modules/Filtering/ (c14d39d4d6)
    —	IOMeshSTL	Modules/IO/ (420a9e22fe)
    —	SplitComponents	Modules/Filtering/ (61019f9e0f)
    —	IOMeshMZ3	Modules/IO/ (17467b4ead)
    —	IOFDF	Modules/IO/ (2b9d7b93d0)
    #6208	RLEImage	Modules/Filtering/ (d6870551ba)
    #6209	MorphologicalContourInterpolation	Modules/Filtering/ (50186c0b0c)

    Modules/Remote/ is now down to 47 entries (was 57).

    Recommended next ingest: SubdivisionQuadEdgeMeshFilter

    Highest-priority Wave 1 module remaining (4★ upstream, pure-ITK QuadEdgeMesh extension, no external deps, small footprint). Natural destination: Modules/Filtering/SubdivisionQuadEdgeMeshFilter/.

    Remaining Wave 1 queue (by stars)

    • SubdivisionQuadEdgeMeshFilter (4★) — recommended next
    • ParabolicMorphology (3★)
    • SmoothingRecursiveYvvGaussianFilter (2★)
    • HigherOrderAccurateGradient (1★)
    • PolarTransform (1★)
    • MultipleImageIterator (1★)

    Wave 2 alternative

    If a user-demand-driven ordering is preferred over star-count, IOScanco is the strongest Wave 2 candidate (⭐ recent user-filed wrapping bug #5920 signals active downstream dependency). Defer to Tier B's external-data weighting if/when CI capacity becomes the bottleneck.
13. hjmjohnson commented on May 9, 2026

    

    hjmjohnson

    on May 9, 2026

    MemberAuthor

    More actions

    Status update — 2026-05-08

    Substantial progress on Phases 1–2 since the last update. The v4 ingest
    pipeline (#6204) is now driving these.

    Phase 1 — additional completed ingests

    Module	In-tree path	Ingest PR
    RLEImage	Modules/Filtering/RLEImage/	#6208
    MorphologicalContourInterpolation	Modules/Filtering/MorphologicalContourInterpolation/	#6209
    Cuberille	Modules/Filtering/Cuberille/	#6205
    IOMeshSTL	Modules/IO/IOMeshSTL/	#6206
    PolarTransform	Modules/Filtering/PolarTransform/	#6211
    SplitComponents	Modules/Filtering/SplitComponents/	#6212
    IOMeshMZ3	Modules/IO/IOMeshMZ3/	#6214
    IOFDF	Modules/IO/IOFDF/	#6215
    SubdivisionQuadEdgeMeshFilter	Modules/Filtering/SubdivisionQuadEdgeMeshFilter/	#6229

    Phase 1 — open ingests

    Module	Status
    AdaptiveDenoising	#6235 (open; Phase 1+CI clean, follow-up PR queued for race-condition refactor)
    TextureFeatures	#6238 (open; Greptile + reviewer concerns addressed)
    PrincipalComponentsAnalysis	#6240 (open; APPROVED, awaiting admin merge over expected ghostflow root-commit)

    Phase 2 — newly archived upstream repos

    All nine landing pages now render the migration notice and the repos
    are marked archived=true:

    Upstream repo	Archive commit
    InsightSoftwareConsortium/ITKSubdivisionQuadEdgeMeshFilter	8540649
    InsightSoftwareConsortium/ITKPolarTransform	745cd10
    InsightSoftwareConsortium/ITKIOFDF	ba44725
    InsightSoftwareConsortium/ITKIOMeshMZ3	65c2849
    InsightSoftwareConsortium/ITKSplitComponents	0b310c5
    InsightSoftwareConsortium/ITKCuberille	a521701
    InsightSoftwareConsortium/ITKIOMeshSTL	0fce299
    KitwareMedical/ITKContourInterpolation	bea4b45
    KitwareMedical/ITKRLEImage	f8ef349

    Other infra

    • normalize-ingest-commits.py deprecation has been superseded by the
      v4 ingest pipeline (COMP: Refine v4 ingestion pipeline — nested-if fix and global whitelist #6204); the linearizing-rewriter problem from the
      v3 path no longer applies.
    • prose-budget.md + kw-prose-budget.py advisory hook landed (PR DOC: Add prose-budget for committed text and warning-level commit-msg hook #6241)
      to keep follow-up commit/PR/comment text within the documented caps.
14. hjmjohnson commented on May 12, 2026

    

    hjmjohnson

    on May 12, 2026

    Last edited by hjmjohnson

    MemberAuthor

    More actions

    Status update — 2026-05-12

    Four additional Wave 1 ingests have landed since the 2026-05-08 update; one remains in review.

    Phase 1 — additional completed ingests

    Module	In-tree path	Ingest PR	Merged
    AdaptiveDenoising	Modules/Filtering/AdaptiveDenoising/	#6235	2026-05-08
    TextureFeatures	Modules/Filtering/TextureFeatures/	#6238	2026-05-09
    PrincipalComponentsAnalysis	Modules/Numerics/PrincipalComponentsAnalysis/	#6240	2026-05-09
    HigherOrderAccurateGradient	Modules/Filtering/HigherOrderAccurateGradient/	#6242	2026-05-12

    Phase 3 — in flight

    • SmoothingRecursiveYvvGaussianFilter — ENH: Ingest ITKSmoothingRecursiveYvvGaussianFilter into Modules/Filtering #6243 (OPEN, awaiting review)

    Phase 3 — Wave 1 remaining (clean ingest, no external deps)

    • ParabolicMorphology (3★)
    • MultipleImageIterator (1★)

    After these two land, Wave 1 Tier-A pure-ITK ingest queue is empty and the remaining work shifts to Wave 2 (richer / external-data) and the Phase 5 docs/Doxygen items.

    Disposition table — flips since 2026-05-08

    Module	Was	Now
    AdaptiveDenoising	?	✓ (#6235)
    TextureFeatures	2	✓ (#6238)
    PrincipalComponentsAnalysis	?	✓ (#6240)
    HigherOrderAccurateGradient	L	✓ (#6242)
15. hjmjohnson

    added a commit that references this issue on May 12, 2026

    COMP: Drop AnalyzeObjectLabelMap remote module (deprecated, not inges…

    ...

    3bbfe22
16. 2 remaining items

    Load more

17. hjmjohnson commented on May 15, 2026

    

    hjmjohnson

    on May 15, 2026

    MemberAuthor

    More actions

    Previously, modules inside ITK had the ITK prefix in their module name (e.g., ITKCommon), while remote modules did not (e.g., GrowCuts). This means that ITK configurations that enabled a particular remote module do not need to be changed. However, there is a minor inconsistency here that may need to be addressed at some point.

    Agreed. I think we should not confound to many improvements in this effort. It is already a tremendous amount of work as it is. I am keeping some private notes (will make public once done) regarding future steps and tasks to address. Thanks for bringing this up.

    👍React with 👍2Reacted by Dženan Zukić and Bradley Lowekamp
18. dzenanz commented on May 15, 2026

    

    dzenanz

    on May 15, 2026

    Member

    More actions

    After the modules themselves are ingested, we have examples on the radar. Some remotes had notebooks, and just running them successfully was another layer of testing. Should we also migrate the issues from the remote repositories here? After closing fixed or no longer relevant issues, of course.
19. hjmjohnson

    added this to the ITK 6.0 Release Candidate 1 milestone on May 15, 2026
20. hjmjohnson commented on May 15, 2026

    

    hjmjohnson

    on May 15, 2026

    MemberAuthor

    More actions

    Should we also migrate the issues from the remote repositories here? After closing fixed or no longer relevant issues, of course.

    @dzenanz I think we should carefully triage migrating issues. In many cases the issues should not be migrated. I would be supportive only of moving issues that can be verified as needing attention. Many of the "it does not work with ITK 5.3.0" or "does not compile on my machine" flavored issues from more than 1 year ago are likely more noise than benefit.

    👍React with 👍1Reacted by Dženan Zukić
21. hjmjohnson commented on May 15, 2026

    

    hjmjohnson

    on May 15, 2026

    MemberAuthor

    More actions

    Some remotes had notebooks, and just running them successfully was another layer of testing.
    @dzenanz I would propose converting those notebooks into Python unit tests (easier to manage and maintain). It should not be too hard to do with agentic coding to get easier-to-maintain tests of equivalent quality or better quality to "notebook does not fail" tests.

    👍React with 👍1Reacted by Dženan Zukić
22. hjmjohnson

    added

    type:InfrastructureInfrastructure/ecosystem related changes, such as CMake or buildbotsInfrastructure/ecosystem related changes, such as CMake or buildbots

    type:EnhancementImprovement of existing methods or implementationImprovement of existing methods or implementation

    area:CoreIssues affecting the Core moduleIssues affecting the Core module

    on May 27, 2026
23. blowekamp commented on Jun 2, 2026

    

    blowekamp

    on Jun 2, 2026

    Member

    More actions

    @hjmjohnson if you have the bandwidth or tokens available could you please integrate ITKTotalVariations? I just merged this PR: InsightSoftwareConsortium/ITKTotalVariation#57 and it includes using an ISC forked version of TVProx now.

    👍React with 👍1Reacted by Dženan Zukić
24. hjmjohnson commented on Jun 2, 2026

    

    hjmjohnson

    on Jun 2, 2026

    MemberAuthor

    More actions

    TLDR; YES! I'll do that today.

    @blowekamp I had previously started that, but shelved the effort for ITKTotalVariation because I saw you were working on it. I was going to reach out to you after the other ingestions were done to ensure I would not conflict with you. This work is almost done! I hope reviews of the open ingestions can be done soon to keep the merge conflicts to a minimum.
25. hjmjohnson

    closed this as completedon Jun 6, 2026
26. hjmjohnson commented on Jun 6, 2026

    

    hjmjohnson

    on Jun 6, 2026

    Last edited by hjmjohnson

    MemberAuthor

    More actions

    🎉 ITKv6 remote-module ingestion is done!

    @blowekamp @dzenanz @N-Dekker @thewtex — I am very happy to announce that I believe the remote-module ingestion, archival, and consolidation effort for ITK v6 is complete. What started as ~57 configure-time *.remote.cmake fetches is now a small, intentional, well-curated set, with every disposition made deliberately. Thank you all — this was a genuinely collaborative push and the review attention made the result far better than a solo effort could have been.

    By the numbers

    Metric	Count
    Modules ingested into the main tree (history- & git blame-preserving merges)	42
    Upstream repos archived read-only (incl. 2 archived without ingestion)	44
    Modules intentionally kept remote (specialty / large-dep / external-tool)	18
    Starting *.remote.cmake fetch entries	~57
    New Modules/ThirdParty/ brought in (proxTV w/ TotalVariation)	1
    Master-issue supersessions consolidated here	7 ( see list below)

    • Integrate some remote modules into ITK proper #3371
    • ENH: Consolidate remote modules into hierarchical category repos #6060
    • Compile error in MeshNoise/test/itkAdditiveGaussianNoiseMeshFilterTest.cxx:56 #5174
    • Re-evaluate modules in the ITK repository and remote modules for ITK 6 #4263
    • Updated, self-maintained resource to list exhaustively existing remote modules #4786
    • NeuralNetworks (Numerics) module missing in recent versions #5557
    • rel. Re-enable doxygen processing of the "Remote" directories. #990

    Every merged ingest preserved the upstream merge topology (no linearized cherry-pick history), so git blame on ingested sources still walks back to the original community authors — their credit is intact in-tree.

    Follow-up / Greptile-identified fixes landed along the way

    The per-PR review passes (human + Greptile draft reviews) caught real defects that were fixed before merge rather than rotting as remote-module bugs — a major argument for ingestion in the first place:

    • IOMeshSWC (ENH: Ingest ITKIOMeshSWC into Modules/IO (with SWC reader hardening) #6392): SWC reader hardening — 6 parser bugs found and fixed; root cause tracked as ITK IOMeshSWC: replace float sample/parent identifiers with an integer type (precision + map-key collisions) #6391.
    • TotalVariation (ENH: Ingest ITKTotalVariation into Modules/Filtering (with ITKproxTV third-party module) #6381) and BSplineGradient (ENH: Ingest ITKBSplineGradient into Modules/Filtering #6385): thread-race fixes during ingest.
    • MeshToPolyData (ENH: Ingest ITKMeshToPolyData into Modules/Filtering #6335): stripped stale WebAssembly/packaging tooling that didn't belong in-tree.
    • Infra hardening: COMP: Fail configure on orphaned remote-module source clones #6378 (fail configure on orphaned remote-module source clones) and COMP: Remove deprecated v3 ingest-remote-module.sh driver #6384 (remove the deprecated v3 ingest-remote-module.sh driver), plus the merge-preserving rewriter (COMP: Deprecate linearizing ingest helper; add merge-preserving rewriter #6162) that replaced the linearizing normalizer.

    PRs / issues migrated to ITK

    Open issues and PRs that were living on the soon-to-be-archived upstream repos were migrated into ITK rather than lost — e.g. the batch transferred as #6338–#6358 and MeshToPolyData's issue #41 → #6389. Each archived upstream now renders a migration notice on its GitHub landing page pointing back at ITK.

    Full ingested-module roster (42)

    AdaptiveDenoising · AnisotropicDiffusionLBR · BoneEnhancement · BoneMorphometry · BSplineGradient · Cuberille · FastBilateral · FixedPointInverseDisplacementField · FPFH · GenericLabelInterpolator · GrowCut · HigherOrderAccurateGradient · IOFDF · IOMeshMZ3 · IOMeshSTL · IOMeshSWC · IOScanco · IOTransformDCMTK · IsotropicWavelets · LabelErodeDilate · MeshNoise · MeshToPolyData · MGHIO · MinimalPathExtraction · Montage · MorphologicalContourInterpolation · MultipleImageIterator · ParabolicMorphology · PhaseSymmetry · PolarTransform · PrincipalComponentsAnalysis · RANSAC · RLEImage · SmoothingRecursiveYvvGaussianFilter · SplitComponents · Strain · SubdivisionQuadEdgeMeshFilter · TextureFeatures · Thickness3D · TotalVariation · TwoProjectionRegistration · VariationalRegistration

    The 18 intentionally kept-remote modules

    BioCell · Cleaver · CudaCommon · HASI · IOOpenSlide · LesionSizingToolkit · PerformanceBenchmarking · RTK · SCIFIO · Shape · SimpleITKFilters · SkullStrip · SphinxExamples · TractographyTRX · TubeTK · Ultrasound · VkFFTBackend · WebAssemblyInterface

    These stay remote on purpose — heavy external dependencies (CUDA, OpenSlide, RTK), external-tool bridges, or specialty scope where a configure-time fetch remains the documented best fit.

    Hats off to everyone who reviewed, tested, and authored the original modules. 🥂 The only remaining work tracked here is Phase 5 documentation (auto-catalog #4786, Doxygen #990, the migration-guide table) — the ingestion itself is done.

    🎉React with 🎉1Reacted by Bradley Lowekamp
27. dzenanz commented on Jun 6, 2026

    

    dzenanz

    on Jun 6, 2026

    Member

    More actions

    Do we already track example migration in some issue? If not, we should create a tracking issue.
28. blowekamp commented on Jun 8, 2026

    

    blowekamp

    on Jun 8, 2026

    Member

    More actions

    @hjmjohnson Great work! thank you.
29. thewtex commented on Jun 9, 2026

    

    thewtex

    on Jun 9, 2026

    Member

    More actions

    @hjmjohnson AMAZING WORK!