New Extension SegmentComparison

[fbrewster]

New extension

Tier 1

Any extension that is listed in the Extensions Catalog must fulfill these requirements.

• Extension has a reasonable name (not too general, not too narrow, suggests what the extension is for). The extension name should not start with Slicer (unless it explicitly provides a bridge between Slicer and a tool or library), because it would make it more difficult to find extensions if the name of many started with the same word.
• Repository name is Slicer+ExtensionName (except if the repository that hosts the extension can be also used without Slicer)
• Repository is associated with 3d-slicer-extension GitHub topic so that it is listed here. To edit topics, click the settings icon in the right side of "About" section header and enter 3d-slicer-extension in "Topics" and click "Save changes". To learn more about topics, read https://help.github.com/en/articles/about-topics
• Extension description summarizes in 1-2 sentences what the extension is usable (should be understandable for non-experts)
• Any known related patents must be mentioned in the extension description.
• LICENSE.txt is present in the repository root and the name of the license is mentioned in extension homepage. We suggest you use a permissive license that includes patent and contribution clauses. This will help protect developers and ensure the code remains freely available. MIT (https://choosealicense.com/licenses/mit/) or Apache (https://choosealicense.com/licenses/apache-2.0/) license is recommended. Read here to learn more about licenses. If source code license is more restrictive for users than MIT, BSD, Apache, or 3D Slicer license then describe the reason for the license choice and include the name of the used license in the extension description.
• Extension URL and revision (scmurl, scmrevision) is correct, consider using a branch name (main, release, ...) instead of a specific git hash to avoid re-submitting pull request whenever the extension is updated
• Extension icon URL is correct (do not use the icon's webpage but the raw data download URL that you get from the download button - it should look something like this: https://raw.githubusercontent.com/user/repo/main/SomeIcon.png)
• Screenshot URLs (screenshoturls) are correct, contains at least one
• Content of submitted json file is consistent with the top-level CMakeLists.txt file in the repository (dependencies, etc. are the same)
• Homepage URL points to valid webpage containing the following:
  • Extension name
  • Short description: 1-2 sentences, which summarizes what the extension is usable for
  • At least one nice, informative image, that illustrates what the extension can do. It may be a screenshot.
  • Description of contained modules: at one sentence for each module
  • Publication: link to publication and/or to PubMed reference (if available)
• Hide unused github features (such as Wiki, Projects, and Discussions, Releases, Packages) in the repository to reduce noise/irrelevant information:
  • Click Settings and in repository settings uncheck Wiki, Projects, and Discussions (if they are currently not used).
  • Click the settings icon next to About in the top-right corner of the repository main page and uncheck Releases and Packages (if they are currently not used)
• The extension is safe:
  • Does not include or download binaries from unreliable sources
  • Does not send any information anywhere without user consent (explicit opt-in is required)

Tier 3

Community-supported extensions.

• Documentation, tutorial, and test data are provided for most modules. A tutorial provides step-by-step description of at least the most typical use case, include a few screenshots. Any sample data sets that is used in tutorials must be registered with the Sample Data module to provide easy access to the user.
• Follows programming and user interface conventions of 3D Slicer (e.g., GUI and logic are separated, usage of popups is minimized, no unnecessary custom GUI styling, etc.)
• The extension can be successfully built and packaged on all supported platforms (Windows, macOS, Linux)
• Maintainers respond to issues and pull request submitted to the extension's repository.
• Maintainers respond to questions directly addressed to him/her via @mention on the Slicer Forum.
• Permissive license is used for the main functions of the extension (recommended Apache or MIT). The extension can provide additional functionality in optional components that are distributed with non-permissive license, but the user has to explicitly approve those before using them (e.g., a pop-up can be displayed that explains the licensing terms and the user has to acknowledge them to proceed).
• All requirements of tiers < 3.

Tier 5

Critically important extensions, supported by Slicer core developers. New Slicer Stable Release is released only if all Tier 5 extension packages are successfully created on all supported platforms.

• Slicer core developers accept the responsibility of fixing any issues caused by Slicer core changes; at least one Slicer core developer (anyone who has commit right to Slicer core) must be granted commit right to the extension's repository.
• Automated tests for all critical features.
• Maintainers respond to questions related to the extension on the Slicer Forum.
• All requirements of tiers < 5.

[pieper]

This looks cool, thanks for submitting it 👍

I didn't look at the code closely, but one thing we do often iterate on is the name of the extension so that users can get a quick idea what it's for. In this case I think SegmentComparison or something like that would get the idea across better.

[fbrewster]

Sure, agreed that's more descriptive! I've updated now

[fbrewster]

Hi @sjh26, I've updated the name on this and then had to make some changes to the CMake file (it wasn't happy with a name with spaces despite being in quotes) but should be good to go now. Am I just waiting for the workflow to run or have I done something stupid?

[cpinter]

Sorry just seeinhg the conversation about the name. We have a SegmentComparison module in SlicerRT that implements the more typical Dice and Hausdorff segment comparison metrics. This new extension (if I saw correctly) adds two different methods. Its name could suggest that it is THE extension containing segment comparison tools, when in reality it provides additional ones.

I don't have any great suggestions, but based on how we do this with the segment editor effects (basic ones in Segment Editor module and additional ones in SegmentEditorExtraEffects), it could be SegmentComparisonExtra or SegmentComparisonAddon, something like this.

[lassoan]

For users (and probably in the long term for the maintainers, too), the simplest would be to have one SegmentComparison extension.

@fbrewster would you consider adding your modules to the existing SegmentComparison extension?

[jamesobutler]

@lassoan There is an existing SegmentComparison extension? Or are you thinking of the SegmentationReview extension (https://github.com/zapaishchykova/SegmentationReview)?

It would seem reasonable to pull the SegmentComparison module out of SlicerRT into its own extension for general use and reuse by various AI workflows since it isn’t RT specific.

[lassoan]

Sorry, I did not remember correctly - as Csaba wrote as well, SegmentComparison is just a module, not a separate extension.

I agree with @jamesobutler suggestion - What do you all think about creating a SegmentComparison extension by moving SegmentComparison module from SlicerRT and add @fbrewster's additional methods? There is a much better chance that users would find segment comparison modules if there was a dedicated extension for them.

[cpinter]

It would seem reasonable to pull the SegmentComparison module out of SlicerRT into its own extension for general use

There is a very practical reason for not having done this yet, although we thought it useful a long time ago. The Dice and Hausdorff metrics are implemented (and well tested, validated) in Plastimatch, which is a really bulky dependency of SlicerRT, also used for a bunch of other things (DICOM-RT support, proton dose computation, gamma dose comparison, etc.).

It has always seemed a huge task leaving Plastimatch behind, but maybe we can start approaching now that we have the powerful AI tools. The most unique feature, which is the proton calculation, is somewhat unstable (crashes more than not when run on larger CTs), and is foreseeable to be replaced by the engine in pyRadPlan (already integrated into SlicerRT). I can collect the list of functions to replace and then re-implement in VTK using Claude for example. We already have tests for the majority of the Plastimatch provided functions, but probably we'll need to add more automated tests before making the change, and we'll need to make sure the new implementations are bullet proof.

What do you think?