Improvements to the Terminologies module.

[muratmaga]

Is your feature request related to a problem? Please describe.

Currently both in Data module and segment editor double clicking the segment name allows renaming the segment in place. Clicking the color of the segment bring the Terminologies window, in which the name of the segment can also be changed. This is a confusing behavior and not conducive to using the terminologies more frequently.

Describe the solution you'd like

Now that Terminologies module is seeing some improvement, to encourage its usage I suggest changing the renaming behavior in segment editor. See discussion here. https://discourse.slicer.org/t/terminologies-questions/27384/11?u=muratmaga

• Renaming behavior (double click on segment name brings the navigator, like clicking on color). If it is possible to do this in python, than it can be SlicerMorph customization before we propose to the community (PR#7983 issued -> superseded by PR#8011, later fix in Fix segment editor name editing #8071)
• Allow user to create custom terminology
  • Export color table from terminology (possibly related to Improve color table node format #7593)
• Making the change in the terminology selection persistent. So if I choose Uberon, next time it should start with uberon
• Highlight/selection confusion. Easier way to select/deselect things.
• https://discourse.slicer.org/t/segment-editor-clicking-eye-to-toggle-visibility-should-not-select-segment/20237

[muratmaga]

adding this thread for discussions: https://discourse.slicer.org/t/improving-the-usability-of-terminology-module/38501

1. renaming behavior change
2. allow user to create custom terminology
3. Export color table from terminology (possibly related to Improve color table node format #7593)

We need these changes for MorphoDepot.

@cpinter will be working on these, but would be good to obtain some consensus.... @lassoan @pieper

[muratmaga]

Also, we need a behavior for user to change the default terminology. I have part of uberon imported, but every time I try to use the terminology module in changing a segment name, I have to click on the dropdown and change it from Segmentation category and type to Uberon. At the minimum, it should remember the last terminology I interacted with.

[cpinter]

Another list from recent email of @muratmaga:

4. Making the change in the terminology selection persistent. So if I choose Uberon, next time it should start with uberon
5. Highlight/selection confusion. Easier way to select/deselect things.
6. Renaming behavior (double click on segment name brings the navigator, like clicking on color). If it is possible to do this in python, than it can be SlicerMorph customization before we propose to the community. (this is the same as #1 above I think)
7. https://discourse.slicer.org/t/segment-editor-clicking-eye-to-toggle-visibility-should-not-select-segment/20237

I just did #5, see #7976

I'd like to discuss #4, because it is not trivial. We have the "default terminology entry" setting in Application settings:

If the user creates a new segment, this terminology entry will be assigned to the segment. From that point on, it does not matter if we have a default terminology context or what it is, because when the user opens the terminology navigator for that new segment, then the context for that entry will be selected. Is it not enough to use this setting for specifying the default terminology?

[muratmaga]

@cpinter Do you want to discuss at forum, where more people might be tracking?

My point is, as I understand, this selection requires a specific term to be set (like Bone, Skull, brain) from a terminology context. I am not sure why there is such a restriction. I am not going to segment always the same thing. So I will have to rename Bone (or whatever I set this to) each time I am going to do something else. From my point of view this behavior is not any different then renaming the "Segment_1", which would have been the segment name of I do not set this property, so I don't see the value. My suggestion have a terminology context selector property so that I can choose my own custom terminology or Uberon or whatever I want to follow, and it doesn't default to Slicer Segmentation Context each time I switch to Navigator.

[cpinter]

Do you want to discuss at forum, where more people might be tracking?

We typically go from free discussion on forum to more concrete discussion on GitHub (if forum discussion reaches that point in the first place), and we can post the link to this issue for those who are interested can participate. We can also mention people here who we want to be involved. But up to you!

I am not sure why there is such a restriction

I see that making one type the default is unnecessary and confusing in your case. In the Slicer terminology Tissue/Tissue seemed super generic, so we went with that as default. I just tried to not specify a type (leaving it at 'None'), and it worked. It caused some errors, however. See this screenshot:

This selection results in this terminology attribute string: Segmentation category and type - 3D Slicer General Anatomy list~SCT^85756007^Tissue~^^~^^~Anatomic codes - DICOM master list~^^~^^, so the context is included.

so that I can choose my own custom terminology or Uberon or whatever I want to follow, and it doesn't default to Slicer Segmentation Context each time I switch to Navigator.

Selecting None within your custom terminology context will do just that. If we get rid of the errors (I added way too many error messages during development, here, in segmentations, in subject hierarchy as well, to be able to debug early issues, but most of them are not needed), then I think this function is done. What do you think? Can you please try?

[muratmaga]

OK, if this is going to facilitate making the custom terminology to be more easily used, it is fine. However, I still think the default behavior should be such that whatever I chose as the last terminology context, it should come as the active one when I open the navigator next time.

I suspect this would be the expectation of the user. Particularly if people are going to have multiple custom terminologies....

[cpinter]

default behavior should be such that whatever I chose as the last terminology context, it should come as the active one when I open the navigator next time.

The problem with this is that when you create a new segment, it will be assigned a default terminology, and then when you open the terminology editor, that terminology entry will be loaded. Forcing the selection of the last used terminology context is in conflict with this feature. I suggested using the default terminology entry feature, because it fulfills both requirements.

[muratmaga]

OK, i got it now.

Not to be argumentative, but wouldn't it be better to decouple this behavior? I mean what terminology context is Segment_1, Segment_2 are assigned to?

[cpinter]

wouldn't it be better to decouple this behavior? I mean what terminology context is Segment_1, Segment_2 are assigned to?

Can you please elaborate? I'm not sure I understand.

@lassoan do you have any comment to the above? Thanks!

[muratmaga]

I am talking about the situation where I have not set up a "default terminology entry" in the Application Settings. In that situation, when I create a new segment, it gets the name Segment_1, which I believe is not part of the any terminology contexts (I might be wrong).

Let's say I renamed this to Cranium from my Uberon ontology. The next blank segment I create will get a name like Segment_2, now when I rename this using Navigator, my expectation would be that Navigator will start from the last chosen context, Uberon in this as, not Slicer Segmentation Terminology. I am not sure I can describe it any more. Perhaps a zoom session would be useful.

[muratmaga]

I guess a related question, if we set the default terminology entry None so that Uberon (or the custom terminology context of the user) is the default, what would be the Segment name generated when I initialize the segmentation and hit the "Add Segment" button. Still Segment_1 or None?

[cpinter]

when I create a new segment, it gets the name Segment_1, which I believe is not part of the any terminology contexts

The name is indeed that, but it does get the Tissue/Tissue terminology, even if nothing was selected explicitly before in the settings. So there is really no situation when the default terminology entry is not set up. The easiest is to go to Application Settings, choose your context, and select the None type, or a generic type if exists. I honestly don't see the difference between this, and being able to select just a context, except that adding that option would complicate things (what happens if the two are in conflict etc.).

my expectation would be that Navigator will start from the last chosen context

I think this is slightly different than being able to select a default context. A possible feature to add could be that when adding a new segment, the terminology of the last added segment would be checked, and that context would de forced with None type (Edit: only if no default terminology entry is defined in settings). Would this work? I think this would be sensible, relatively clean, and would not take a huge effort. The reason I say it is sensible is that you already have a segmentation by that time, and having explicitly chosen a non-default terminology, we can assume that for the subsequent segments you want to stick to the same context.

Perhaps a zoom session would be useful.

Possibly, if my last suggestion is not appealing. However, we can be discussing here for days and days, but then when @lassoan or @pieper looks at the PR, they might have a totally different opinion, and nothing can be integrated without their consent. That's why I asked for feedback early on.

Still Segment_1 or None?

My guess is Segment_1, but need to try.

[cpinter]

I added a PR about the renaming behavior:
#7983
There is a video as well showing how it works.

[cpinter]

I have been investigating the "segment selection on clicking eye" issue. I think the only way basically would be to subclass the QTableView and override its mousePressEvent in a way that it stops the event from propagating if the click happens in the visibility column (but still show/hide the segment). This would not be a small task. @muratmaga do you want me to proceed with this?

Also, we'd need to discuss the creation of custom terminology. It is a very open question with lots of possible solutions and implementations. Do you have something in mind?

[muratmaga]

If you don't think "segment selection on clicking eye" is a small thing, I think we have to prioritize the custom terminology due to the funding.

For that, I think for starters maybe adding a "Add to my custom terminology" button to the navigator, so when I am renaming a segment and choosing a color, I click on this, and it goes into my custom terminology context.

Another behavior maybe is I create an empty segmentation with multiple segments that I custom name and assign colors, then (Under segmentations module perhaps?) there is an option that says "Generate custom terminology from Segments".

As you said there are many possibilities on UI. I am not sure if this is going to give you all the information you will need to create the JSON though.

Another option is like a little interactive editor using the table layout in slicer, where each row is property of a term that needs to be set (color, names, unique identifier, whether symmetrical or not). And then from this file, it is possible to export a json. this is sort of similar to what we have done previously as a standalone python module. I would like this to be doable inside the Slicer though.

[muratmaga]

Something like this: https://github.com/Imageomics/slicerMorph_JSON_generator/blob/main/test_data/terminology_test.csv

Perhaps, we might be even able to use this structure to generate a color table as well?

[cpinter]

Thanks Murat! I'll come back with a concrete suggestion soon.

A possible feature to add could be that when adding a new segment, the terminology of the last added segment would be checked, and that context would de forced with None type (Edit: only if no default terminology entry is defined in settings). Would this work? I think this would be sensible, relatively clean, and would not take a huge effort.

What do you think of this?

[cpinter]

If you don't think "segment selection on clicking eye" is a small thing

I tried a simple thing based on this forum thread (setting the Qt::ItemIsSelectable flag to false for all the columns except the name column), but it worked differently than expected: the decorator was not enabled (so show/hide for example didn't work), but selection was still made, so just the opposite of what I wanted. The thread also concludes that the mouse events need to be handled explicitly, which is what I suggested above. So a second round resulted in the same thing, sorry.

[lassoan]

Eye icon

@cpinter If we add a widget (such as a pushbutton with custom icon to show the eye) in the table then I think it will not change the item selection. See for example in the table view in the Tables module:

2024-10-09_09-37-43.mp4

Since this issue is not related to terminology, it would be better to spin this out to a separate github issue and discuss it further there.

Terminology editing

@muratmaga Would it help if users could create/edit/combine terminology files in standard .csv file format in Excel?

We would use this simple "color table with terminology" labels.csv file format for deep learning segmentation models in Slicer (MONAIAuto3DSeg, TotalSegmentator already bought in) and several other key developers from various packages support the idea, too.

LabelValue,Name,Color.R,Color.G,Color.B,Color.A,Category.CodingSchemeDesignator,Category.CodeValue,Category.CodeMeaning,Type.CodingSchemeDesignator,Type.CodeValue,Type.CodeMeaning,TypeModifier.CodingSchemeDesignator,TypeModifier.CodeValue,TypeModifier.CodeMeaning,AnatomicRegionSequence.CodingSchemeDesignator,AnatomicRegionSequence.CodeValue,AnatomicRegionSequence.CodeMeaning,AnatomicRegionModifierSequence.CodingSchemeDesignator,AnatomicRegionModifierSequence.CodeValue,AnatomicRegionModifierSequence.CodeMeaning
1,Intracerebral_Haemorrhage,100,120,140,255,SCT,49755003,Morphologically Altered Structure,SCT,50960005,Hemorrhage,,,,SCT,113305005,Cerebellum,,,
2,Intraventricular_Haemorrhage,120,120,140,255,SCT,49755003,Morphologically Altered Structure,SCT,50960005,Hemorrhage,,,,SCT,279245009,Ventricular system of brain,,,
3,Subdural_Haemorrhage,160,120,140,255,SCT,49755003,Morphologically Altered Structure,SCT,50960005,Hemorrhage,,,,SCT,54214006,Subdural space,,,
4,Subarachnoid_Haemorrhage,10,120,140,255,SCT,49755003,Morphologically Altered Structure,SCT,50960005,Hemorrhage,,,,SCT,35951006,Subarachnoid space,,,
10,Brain_Parenchyma,50,120,140,255,SCT,123037004,Anatomical Structure,SCT,836432005,Parenchyma of brain,,,,,,,,,
11,Subarachnoid_Space,90,120,140,255,SCT,123037004,Anatomical Structure,SCT,35951006,Subarachnoid space,,,,,,,,,
12,Dura_Mater,30,120,140,255,SCT,123037004,Anatomical Structure,SCT,18545000,Dura mater,,,,,,,,,
13,Septum_Pellucidum,40,120,140,255,SCT,123037004,Anatomical Structure,SCT,70146006,Septum pellucidum,,,,,,,,,
14,Cerebellum,110,120,140,255,SCT,123037004,Anatomical Structure,SCT,113305005,Cerebellum,,,,,,,,,

Since this is a color table, it will be editable in Colors module in Slicer - entries can be added/removed/modified using GUI. We could improve this with more features, such as copy/move entries from other color tables, cut/copy/paste clipboard operations.

We could also add a "Export segments to color table" feature very easily, which would export current segments to a color table. Allowing the current segmentation to be used as a template for new segmentations.

We could also make the terminology selector widget support selection of color table nodes (which could be implemented by generating terminology json from the color table node; since color tables are not modified frequently, it would not need to be regenerated often, and since color tables usually contain only up to a few hundred items, regeneration would be very fast anyway):

[cpinter]

Thanks Andras! Just quickly regarding this

Since this issue is not related to terminology, it would be better to spin this out to a separate github issue and discuss it further there.

there is an issue: #5290

I'll digest the other topic a bit more.

What I've been thinking along was right-clicking a type, and adding entries to a temporary terminology that could be edited/exported in the Terminologies module (which is really not useful at the moment).

[muratmaga]

@muratmaga Would it help if users could create/edit/combine terminology files in standard .csv file format in Excel?

@lassoan that's exactly what we are doing right now with our python module I linked above. We trimmed the fields to a minimum (since most everything else is fixed from our perspective)

This works, and probably is the way to go for creating/editing larger custom terminologies. But what about a situation where you might have 5-6 undergrads doing a segmentation for a class (or a for the PI). You want to use them the same terms, same colors etc... There really should be an easier way to achieve that....

[lassoan]

What I've been thinking along was right-clicking a type, and adding entries to a temporary terminology that could be edited/exported in the Terminologies module (which is really not useful at the moment).

Yes, this could work, but instead of modifying terminologies, we could modify a color table node (which contains terminology codes).

A real-life analog could be paint in bottles -> palette -> canvas. You buy a set of bottles of paint = terminology. You then select a subset of them and put them on your palette = color table (in custom position, maybe slightly modify its color compared to the original). Then you can paint with those colors on your canvas = segmentation (again color may be slightly modified when used there).

[muratmaga]

@muratmaga I assume you have reasons for rolling your own terminology with UBERON

We do. We work with all vertebrates, not just humans and/or a few model species. UBERON is the most comprehensive cross-species anatomical ontology. Even then we have encountered issues of missing terms and such.

[muratmaga]

Should anyone be able to upload a file and automatically accepted as long as some basic checks are passed (e.g., github pull request process with automatic merge)?

We probably need some curation and structure, not sure if automatically merging with minimal check is a good idea. Maybe like a regular PR with manual review (like we are doing in morphoDepot?). Imagine everybody is checking in their own VTK rendering presets so that they can access on their new computers/lab. If we have hundreds of files to choose from that might hinder the usability.

[fedorov]

It might be helpful if each file is accompanied by another file with the metadata - what it is, what is its purpose, author. Otherwise I don't know how one could navigate that content. This could be JSON/Yaml, and in case of a remote file by reference it would be just JSON/Yaml with the link to the specific commit of the external file elsewhere.