Slicer
Add SegTemplateEditor extension
This pull request adds the metadata for a new 3D Slicer extension: SegTemplateEditor.
Extension Overview
SegTemplateEditor is a simple extension that allows users to:
- Create and save custom label groups for segmentation
- Apply visually distinct colors to each label using golden-ratio hue stepping
- Load, reuse, and apply label groups via GUI
- Automatically apply selected groups to the Segment Editor
Repository: https://github.com/esheo-skia/Slicer-SegTemplateEditor
License: MIT
Category: Segmentation
Checklist for Tier 1 (All Completed)
- [x] Repository follows naming convention:
Slicer-SegTemplateEditor - [x] Extension has license: MIT
- [x] README, icon, and basic documentation provided
- [x] Extension metadata file (.s4ext) is complete
- [x]
SegTemplateEditor.jsonhas been added - [x]
scmrevisionusesmain(not a specific commit hash) - [x] Public GitHub repository is accessible
- [x] Icon URL uses raw format and is accessible
- [x] Screenshot URLs added
- [x] Extension does not include or download binaries, and does not send data
- [x] GitHub wiki, projects, and discussions have been disabled
All CircleCI checks have passed and the repository satisfies all Tier 1 requirements.
Looking forward to review and feedback from the core team.
Hi, my name is Lena, a computer science student working with Andrey Fedorov (@fedorov). I am currently working on an extension of the Segmentation Verification module. During development, we came across your module and gave it a try. First of all, thank you for making it available! I wanted to share some feedback and suggestions that might be helpful if you're planning future updates.
One thing we found a bit challenging was understanding the intended functionality of the module based on the current documentation. It would be great if the README could provide a bit more context about the purpose and capabilities of the module — that would make it easier for new users to get started.
In our experience, the segment names weren’t preserved when we applied the selected group — instead, segments were automatically named “Segment_1”, “Segment_2”, etc., without the original label names. It's possible we missed something, but this made it hard to track specific structures. Also, since the colors are randomly assigned, some ended up being very similar, which made distinguishing them visually a bit difficult. Perhaps colors could be chosen to be more distinct by default?
Label Names we wanted to add
Label names we got; The shades of green look very similar
Another issue we encountered was that a new segmentation was created even when no volume was loaded, which didn’t behave as expected. Also, when using the Segment Editor, regardless of which segmentation is selected, new segments always seem to be added to the same segmentation node.
It seems like a Volume is created when no Volume is loaded beforehand. When you load a volume afterwards you can switch between both volumes
Switching back and forth between volumes enables the add button although no correct volume is selected
One of the advantages of creating a segmentation directly using the Segment Editor (in combination with the Terminologies module) is that it allows users to create segmentations with standardized metadata — which is particularly important when exporting segmentations to DICOM. It might be helpful if your module could recognize matching segment names and, when a match is found, automatically apply the corresponding color and metadata from the terminology database. This would make the module especially valuable for workflows involving DICOM export.
If you consider adding that feature, it might also be worthwhile to create a Terminology JSON File instead of a JSON file only containing name and color (Terminologies)
Thank you again for your work on this module! Best regards, Lena
Hi Lena @.***),
Wow — thank you so much for taking the time to try out my module and for sharing such detailed and thoughtful feedback! I really appreciate your dedication to contributing to the Slicer community, and your input means a lot.
You're absolutely right about the documentation. After reading your message, I realized that the current README doesn't clearly explain the purpose or functionality of the module, especially for first-time users. I’ll definitely work on improving it by adding clearer descriptions and usage instructions in the next update.
Thank you also for pointing out the issue with segment names being overwritten with generic labels like “Segment_1”, “Segment_2”, and how the random color assignment sometimes results in very similar colors. I hadn’t caught those issues before — I’m sorry if they caused any confusion. In the upcoming version, I’ll make sure label names are preserved and that the color palette is improved for better visual distinction. Your screenshots were super helpful in identifying the problem!
I also appreciate you describing the unexpected behavior when no volume is loaded and how new segments always end up in the same segmentation node in the Segment Editor, regardless of which one is selected. That’s definitely something I need to fix to make the module behave more intuitively and reliably.
I think your idea about integrating the Terminologies module is fantastic. Automatically applying standardized metadata and colors based on segment names would make the module much more useful, especially for DICOM workflows. I’ll be looking into how to support this kind of functionality, and I really like your suggestion about using a Terminology-based JSON format.
Thanks again for all your thoughtful input — I’ll take everything you shared into account as I work on the next version. Your feedback has been incredibly helpful!
Best regards, Eunseo Heo @.***)
2025년 5월 9일 (금) 오전 6:09, LenaGiebeler @.***>님이 작성:
LenaGiebeler left a comment (Slicer/ExtensionsIndex#2171) https://github.com/Slicer/ExtensionsIndex/pull/2171#issuecomment-2864315034
Hi, my name is Lena, a computer science student working with Andrey Fedorov @.*** https://github.com/fedorov). I am currently working on an extension of the Segmentation Verification module. During development, we came across your module and gave it a try. First of all, thank you for making it available! I wanted to share some feedback and suggestions that might be helpful if you're planning future updates.
One thing we found a bit challenging was understanding the intended functionality of the module based on the current documentation. It would be great if the README could provide a bit more context about the purpose and capabilities of the module — that would make it easier for new users to get started.
In our experience, the segment names weren’t preserved when we applied the selected group — instead, segments were automatically named “Segment_1”, “Segment_2”, etc., without the original label names. It's possible we missed something, but this made it hard to track specific structures. Also, since the colors are randomly assigned, some ended up being very similar, which made distinguishing them visually a bit difficult. Perhaps colors could be chosen to be more distinct by default? Label Names we wanted to add Bildschirmfoto.2025-05-08.um.15.53.34.png (view on web) https://github.com/user-attachments/assets/826d7909-7581-4d28-a784-c8995c19ee80 Label names we got; The shades of green look very similar Bildschirmfoto.2025-05-08.um.15.32.56.png (view on web) https://github.com/user-attachments/assets/db4163cb-fcb4-49f4-baed-7fbd6f4c6275
Another issue we encountered was that a new segmentation was created even when no volume was loaded, which didn’t behave as expected. Also, when using the Segment Editor, regardless of which segmentation is selected, new segments always seem to be added to the same segmentation node. It seems like a Volume is created when no Volume is loaded beforehand. When you load a volume afterwards you can switch between both volumes Bildschirmfoto.2025-05-08.um.15.58.24.png (view on web) https://github.com/user-attachments/assets/bebfcf0c-2c93-4f1c-be73-3a2f8139d320 Switching back and forth between volumes enables the add button although no correct volume is selected Bildschirmfoto.2025-05-08.um.15.57.29.png (view on web) https://github.com/user-attachments/assets/3b6cefb6-1e1e-437c-97b9-b2accd519842
One of the advantages of creating a segmentation directly using the Segment Editor (in combination with the Terminologies module) is that it allows users to create segmentations with standardized metadata — which is particularly important when exporting segmentations to DICOM. It might be helpful if your module could recognize matching segment names and, when a match is found, automatically apply the corresponding color and metadata from the terminology database. This would make the module especially valuable for workflows involving DICOM export.
Bildschirmfoto.2025-05-08.um.16.01.04.png (view on web) https://github.com/user-attachments/assets/e2f313d6-8d90-4642-8860-3426e3bc5c47 Bildschirmfoto.2025-05-08.um.16.01.23.png (view on web) https://github.com/user-attachments/assets/99d27254-b749-409c-a02a-dbbd6121fde9
If you consider adding that feature, it might also be worthwhile to create a Terminology JSON File instead of a JSON file only containing name and color (Terminologies https://slicer.readthedocs.io/en/latest/user_guide/modules/terminologies.html )
Thank you again for your work on this module! Best regards, Lena
— Reply to this email directly, view it on GitHub https://github.com/Slicer/ExtensionsIndex/pull/2171#issuecomment-2864315034, or unsubscribe https://github.com/notifications/unsubscribe-auth/BBZDSJ6MQGXDGSNLDSMTO6D25PBW5AVCNFSM6AAAAAB4S4OFMSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDQNRUGMYTKMBTGQ . You are receiving this because you authored the thread.Message ID: @.***>
--
Eun Seo Heo | 허 은 서
Labeling Researcher
www.skia.kr +82.10 9757 4686
Hi @jcfr, this PR is now ready for review!
The extension structure has been finalized, and the previously included labels.json file has been removed.
Let me know if there’s anything else I should update. Thanks a lot for your time!
Hi @jcfr,
I've removed the .gitignore file and all CI checks have now passed (including check-filenames).
Could you please approve the workflow so it can proceed?
Thanks again for your time!
Hi @jcfr,
The pre-commit hook is currently failing due to check-jsonschema not recognizing the structure of LabelNameGenerator.json.
This file follows the Slicer extension metadata format, which is consistent with other accepted entries in the ExtensionsIndex. Since it's not intended to comply with a general JSON schema and $schema is not required in this context, the failure appears to be a false positive.
All other checks have passed successfully.
Would you be able to approve the PR despite this schema check? Thank you!
It appears LabelNameGenerator is not following the JSON schema defined for the Slicer extensions index. See for example recently accepted extension:
https://github.com/Slicer/ExtensionsIndex/blob/ad5f3b9ed16e6e3deaf5893e04f8525190999617/NNInteractive.json#L1-L9
I would add that the new color table feature in recent Slicer Preview Releases allow users to define a text file (in CSV format) that describes a list of segments (name, color, label value, terminology codes). The user can choose the color table in the terminology selector (when double-clicking on a segment name or color) and easily choose a label from there. This may offer a better user experience than a separate module.
That said, a module like yours could be still useful in automatically generating colors and offer other tools that make creating and editing color tables (or as you call them "segment groups") more convenient.
I would add that the new color table feature in recent Slicer Preview Releases allow users to define a text file (in CSV format) that describes a list of segments (name, color, label value, terminology codes). The user can choose the color table in the terminology selector (when double-clicking on a segment name or color) and easily choose a label from there. This may offer a better user experience than a separate module.
That said, a module like yours could be still useful in automatically generating colors and offer other tools that make creating and editing color tables (or as you call them "segment groups") more convenient.
Thank you @lassoan for the insightful suggestion!
Indeed, the color table feature via CSV + terminology selector is very convenient — I’ll definitely consider integrating it or aligning the UX with that approach in the future.
For now, LabelNameGenerator aims to offer quick label group management with automatic color assignment, but I really appreciate your input and will keep refining the concept based on your feedback.
Hi @jamesobutler @lassoan, Just wanted to follow up on this PR — it’s been a little over a week since submission. Please let me know if there’s anything further I should address. Appreciate your time!
I would be OK with getting this extension added to the extensions index as tier 1, but before doing that we should make sure that the name is good (because later it is much more complicated to change the name). As far as I can tell, the extension is not for generating label names. Instead, it helps with generating and managing color tables (set of preconfigured segments the user can choose from). If we want to be a bit more generic then we could say it helps creating segmentation templates. Could you think of names that better reflect what the extension does (and aspires to do)?
I would be OK with getting this extension added to the extensions index as tier 1, but before doing that we should make sure that the name is good (because later it is much more complicated to change the name). As far as I can tell, the extension is not for generating label names. Instead, it helps with generating and managing color tables (set of preconfigured segments the user can choose from). If we want to be a bit more generic then we could say it helps creating segmentation templates. Could you think of names that better reflect what the extension does (and aspires to do)?
Thank you for the thoughtful feedback!
Based on your suggestion, I'm considering renaming the extension to SegSetTemplater, since it more accurately reflects what the extension does (and aims to do in the future).
The tool helps users define, reuse, and apply groups of segments with preassigned names and colors — effectively acting as reusable templates for segmentation workflows. As it evolves, I’d also like to support import/export in CSV color table format and template sharing between users.
Does the name “SegSetTemplater” sound appropriate to you, or would you suggest an alternative? Happy to update accordingly!
Hi @lassoan, just a gentle follow-up regarding the proposed name change to SegSetTemplater.
If the name looks good to you, I’ll go ahead and update the extension name and related files accordingly.
Thanks again for your time and guidance!
SegSetTemplater is much better, but not yet sufficiently self-explaining. The Set part I don't understand, probably we can skip. Something like SegmentationTemplates, SegmentationTemplateEditor, SegTemplateEditor, SegTemplateUtil etc. would be better.
SegSetTemplateris much better, but not yet sufficiently self-explaining. TheSetpart I don't understand, probably we can skip. Something likeSegmentationTemplates,SegmentationTemplateEditor,SegTemplateEditor,SegTemplateUtiletc. would be better.
Thanks for the feedback, @lassoan!
I’ll proceed with the name change to SegTemplateEditor as suggested.
Will update the extension name and all related files accordingly.
Hi @lassoan,
The extension has been fully renamed to SegTemplateEditor as discussed:
- Repository name updated:
Slicer-SegTemplateEditor - All folder and file names updated (e.g.,
SegTemplateEditor.s4ext, icons, screenshots) - All metadata and references revised (including
.s4ext, README, JSON entry)
PR description, filenames, and repository structure are now fully aligned.
Thanks again for your feedback. Let me know if there's anything else I should adjust!
Hello @lassoan and @jcfr,
I'm checking in on Pull Request #2171.
I've incorporated all the previous feedback, including renaming the feature to "SegTemplateEditor," and all the continuous integration checks have now passed. I believe all Tier 1 requirements have been addressed.
Please let me know if there's anything else needed from my end to move forward with the merge.
Thanks for your time and consideration.
Hi @lassoan @jcfr, just checking in again on this PR.
It has been a little while since the last update, so I wanted to gently follow up.
All feedback has been incorporated, CI checks have passed, and the extension is now fully aligned with Tier 1 requirements.
If there's anything else you’d like me to adjust, I’d be happy to help — otherwise, I’d greatly appreciate your final review and merge when convenient.
cc @pieper @ebrahimebrahim @jamesobutler — feel free to take a look as well, if you have any thoughts!
Thank you again for your time and consideration!
The top-level CMakeLists.txt should contain the extension metadata (EXTENSION_ICONURL, etc.) as it is shown in the extension template. Please restore those lines and update their content, because without this information the extension package build will fail.
@lassoan Thank you for the feedback! I've updated the top-level CMakeLists.txt with all the required extension metadata (EXTENSION_ICONURL, etc.) as requested.
Hi @lassoan, PR #2171 has been ready for merge with all checks passing since last week. Is there anything else you'd like me to address before it can be merged?