-
Notifications
You must be signed in to change notification settings - Fork 258
Add LabelNameGenerator extension metadata #2171
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
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? 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. 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. 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! |
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)
<#2171 (comment)>
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
<#2171 (comment)>,
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 |
Hi @jcfr, I've removed the Thanks again for your time! |
Hi @jcfr, The 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 All other checks have passed successfully. |
It appears LabelNameGenerator is not following the JSON schema defined for the Slicer extensions index. See for example recently accepted extension: ExtensionsIndex/NNInteractive.json Lines 1 to 9 in ad5f3b9
|
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. |
- Removed non-schema fields (extension_id, author, description, etc.) - Added $schema and tier - Ensured metadata matches required structure for Tier 1 extension
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. |
This pull request adds the metadata for a new 3D Slicer extension: LabelNameGenerator.
Extension Overview
LabelNameGenerator is a simple extension that allows users to:
Repository: https://github.com/esheo-skia/Slicer-LabelNameGenerator
License: MIT
Category: Segmentation
Checklist for Tier 1 (All Completed)
Slicer-LabelNameGenerator
LabelNameGenerator.json
has been addedscmrevision
usesmain
(not a specific commit hash)All CircleCI checks have passed and the repository satisfies all Tier 1 requirements.
Looking forward to review and feedback from the core team.