I am reviewing the newly integrated functionality. Everything seems to work well, but I think we need some clarification and some minor functionality tweak.
When I am creating my own custom color table with terminologies, do I need to create 0 Background entry with color (0,0,0) or is that automatically appended? Because all color tables I am aware of that has that entry. and it wasn’t clear to me. If it is necessary, perhaps auto-populate that field.
I have a little issue with opacity being always 0 for all blank entries, which complicated setting the color from the palette. But it is a minor one. I suspect most of the time people will either choose from the terminology module or enter the RGB code in the table. Otherwise table creation seems to work well.
When I am using this color table during segmentation, Terminology selector seems to keep defaulting to Slicer’s own terminology. Can we make the change that Terminology module opens with the latest selected terminology/color table from the top drow down.
I will keep reviewing more thoroughly, but things seems to work well for me beyond these minor issues.
Thanks @lassoan@cpinter and everyone else who contributed to the discussion and implementation.
No need for defining a color for the 0 value for segmentations.
0 always corresponds to background, so it is never mapped to a segment. Its only use is when somebody applies the color table to display a labelmap volume and he wants to set a background color&opacity.
An entry can be made undefined by clicking the delete color (red -) button above the color table. The color will not be undefined if you set to a specific color (even if you set it to, RGBA=(0,0,0,0)).
The terminology for a segment is copied from the previous segment. You got the default terminology because you added all your segments, which were all set to the default terminology entry.
The solution is to add the first segment, set the terminology from the color table, and then add all the other segments.
We could tune this behavior to make it more intuitive. We could probably avoid setting a default terminology when adding a new segment (leave the terminology undefined). Then we would always look up the context from any previous segment that has defined terminology.
It seems that you keep clicking on the color box, so the application is guessing that you just want to change colors and may be frustrated to see a terminology selector. You can confirm that you want to keep using the terminology selector even when clicking the color box by selecting “Keep using terminology selector”.
It is all supposed to be self-explanatory, so the fact that you need to ask for clarification means that we need to improve things. Let us know if you have any suggestions about what and how to change.
I don’t think I clicked on the colors, but the actual terms. So here are my steps:
I created a custom color table with 6 entries from Uberon
Loaded a volume and right-click to start the segmentation
I added a blank segments, which initialized as Segment_1, I double-click the name and the terminology module came. I chose my color table, and then picked up a term.
I added another blank segment, which came as Segment_1 (or might have been Segment_2), which I double-clicked to set. Terminology selector came with my color table prepopulated (as I wanted it to be). I picked up another term.
I repeat this procedure and at the 5th or 6th one, this window came up.
Thanks for the further testing. I’ve checked the implementation and the actions that we count is the number of times the user selects a custom segment name or color (it does not matter if you double-click on the color box or the segment name). However, when the user chose a color from the color table, it was always counted as a custom segment name/color selection. I’ll submit a fix tomorrow.
I think the main issue is clicks to choose a proper label for a segment from color table should not count towards that popup message, because that’s the intended usage, and it confuses the user (making them think they are not doing something right).
The popup meant to bring back the older renaming style for people who do NOT want to use terminology module.
Thanks! I’m curious of the explanation of @lassoan because as I recall this feature was not supposed to do this, so just want to know what went wrong and what we want to do instead.
Maybe I am doing something wrong, but this is the labelmap I am getting when I use Segmentations module to export a labelmap from a segmentation I created using color table:
To create the labelmap, I went to the segmentations module, choose Export labelmap, click on Use Color Table Values and specified my custom color table.
If I don’t do that, but simply right-click in SH to export as a labelmap, I don’t get my Color Table 0 being assigned to the background, but then assigned indices are not the ones I specified in the color table (Based on color table lateral parasympasial foramen, blue segment, should have label value of 3, but instead it got 1, since it is the first segment)
Yes, the issue is that the bacground label is missing.
Did you create the color table manually? Did you set a color and terminology for the background (label value=0)?
If yes then we have to somehow make it more difficult to specify a color and terminology for label=0, because a custom background is very rarely needed (and never needed if you use the color table for segmentation conversion). Maybe a warning popup or hiding the label=0 entry by default would be sufficient?
I used the colors module to create the table. The first entry for “0”, hence I asked whether I should create a background label at the beginning of this thread. So it appears, while I don’t need to create an explicit 0=background label, I also shouldn’t have created a specific label entry at 0, but instead start from 1.
is that correct way of explaining? Is there any reason 0 is not auto-populated as a background?
The label=0 entry is always left empty by default. You only ever see the background label if you explicitly uncheck the “Hide empty colors” checkbox. If you add colors using the green “+” button (same way as for segments) then you never ever see the background label and never get tempted to specify some custom name or color for it.
But I completely understand that since the spinbox for modifying the number of colors is displayed quite prominently, you may decide to use that to increase the table size, and then you don’t understand why you don’t see any change, so you uncheck the “Hide empty colors” checkbox, which then shows the background color as well.
Maybe moving the “Number of colors” entry to some advanced section could help. Or maybe even better would be to have a separate checkbox to show the background label (in an advanced section, so that only very advanced users would find it)?
Actually my usage was different: After I click on create a new color table button, instead of using + or -, I simply entered the number of labels I wanted in the field that says “Number of Colors”, as I thought that was expected of me.
Now, I understand for this use case I need to use the + and - buttons, but I am not sure it is quite obvious.
I still think it might be a good idea to slightly differentiate this type of color table creation from regular color table? That way maybe the number of colors is not an editable field?
Yes, we definitely need to change the GUI to make it easier to use as intended. Hiding the background color even if showing other undefined colors will be needed but maybe also the number of colors spinbox can be moved to an advanced section.
