I have found it confusing that 2 similar looking color objects bring up different options.
First, there is the color selector in a node table such as in this table in the Markups module, but also used in the Segment Editor module and the Data module.
Second, there is this color selector used in various place mode widgets including the markups toolbar
It is confusing that these look the same (square color that can be double-clicked), but bring up different options. The version in the table brings up a qSlicerTerminologySelectorDialog and the other brings up a simple QColorDialog.
qSlicerTerminologySelectorDialog
QColorDialog
Does a terminology selector dialog make sense in the context of the Markups module? Would you set markups color primarily based on the terminology? Or is terminology primarily used in the context of segmentations?
Currently it feels like terminology is being forced onto the user first and simple color is the supported secondary option. It would seem to make sense for simple color selection to be the primary first option, with the support for the user to have color selection have more functionality by supporting terminology selection as the advanced option. This may be a QColorDialog is shown first with a button to open up the Terminology selector as the second option if they cannot be combined into a single dialog.
The terminology selector does not make sense for markups in my use cases. Also, many of the terminology label colors are dull and for fiducial visibility I prefer brighter colors. I agree with making QColorDialog the primary option.
@pieper or @lassoan Do you know the history behind color selection in Slicer? Is there a historical reason why terminology color usage is presented as the primary option instead of the simple color option?
We got this implementation when we switched from node combobox to subject hierarchy tree and made us realize how much sense it makes, so we kept this behavior.
Yes, I think this is true. It encourages users to consider specifying what the item is, and provide for free spell-checked, translatable, machine-readable, archival-quality name and automatic default color.
Actually, you would benefit from using terminology selector for landmarking. It would make your templating workflows much more robust if you specified the template, because you would actually know what that template is, instead of trying to deduce it from the landmark points that you have in the markups file.
You can add your own terms by specifying a coding scheme (it could be 99SLICERMORPH), code name (displayed name, such as Maga2019 Mouse skull template) and code value (machine-readable, language and spelling independent value, such as TPL-MOUSE-001) triplets in a json file.
It seems that the huge advantages of using standard terminology is not obvious to users. Hiding this feature would be easy, but I think we should improve its usability instead. For example, if the user does not find an existing term then we could offer to save it as a new term.
For my workflow Iām usually segmenting the same thing multiple times. If I have multiple subcutaneous tumors in a Volume, I would not want these segments to all have the same color. I care about color for uniqueness as we also have a custom statistics table where the segment name is colored as well for easier matching by color. We donāt have human data or use the DICOM standard, so DICOM standard terminology colors arenāt important to us. We care about the measurement first.
How colors are set up currently it takes more effort to have less information. However I would advocate where more effort should lead to more information where you start with the simplest form of information first. Such as simple color first with the ability to add more terminology information as the secondary option. Terminology requires more effort and time so terminology is something I donāt frequently care about.
This is a very specific and reasonable need, which would not be hard to address.
Using coded values instead of random custom strings to describe meaning or content of something is not related to DICOM or human data.
Terminology allows the users to specify more information (coded term, color) with less effort: double-click the terminology selector, start typing whatās there (for example, type mas for mass), hit Enter and you are done.
I see that things should be improved, because if you want to use ātumorā instead of āmassā then it should be trivially easy to create a new term. For example, when you first type ātumorā, Slicer should ask if you want to create a new term from this. Generating unique colors would be important, too.
It would be easy to just add an option to the application settings that would allow tucking away terminologies, but I think we can make terminologies work better, so that they would not get in the way and users would understand how it helps them. It could work similarly to how auto-complete works in all modern software.
The problem described here is a persistent one dating back to the use of color lookup tables. LUTs associated integer labels, RGB or RGBA colors, and descriptive strings, By locking these three items, the locked three very different concepts together: data description, rendition style, and semantic meaning.
Things are a bit more advanced and flexible with terminologies in Slicer today. The data description piece is now sort of separate (we donāt have to label our models with the same integer labels used in a label map) but the conflation of semantic label and style remains. āBoneā isnāt a color, though in an anatomy atlas bone may have a characteristic color. In such a context, bone and a bone color might be directly mapped. On the other hand, in a population study of livers, each subjectās liver might be uniquely colored. In a lesion study, the lesions might be colored by a quantitative value.
In relational database terms, we might want to join color to a model based on different values such as semantic label or subject ID or lesion volume. We might want to do they do that dynamically for data exploration. Or we might want to do multiple types of joins at once: a base layer thatās an anatomy atlas overlaid with fiducials colored using a different semantic scheme.
As Andras says, semantic labeling using terminologies is very useful. But a richer way to use visual colors or styles to depict information in biomedical visualization is also very useful, as is a broader concept of semantic labeling (for instance, by locally defined fiducial or landmark type rather by some standardized vocabulary). Addressing the issue starts with understanding and disambiguating these different concepts. Then we can build more flexible visualization mechanisms and methods.
By the way, the colors in the default Slicer anatomy color table were created by using a spectrophotometer to measure the colors used in print atlases for various anatomical materials. Thatās one reason why the colors are not highly saturated. It was a fun project to create more universally recognizable anatomical atlases, but thatās not the only medical application of Slicer.
I see how using terminology can make things more helpful, but if I donāt want to code a meaning to a color then that shouldnāt be harder than setting a terminology.
A simple color selector of the basic colors like the QColorDialog with a terminology selector below that would be all I would need for a better experience. Currently using terminologies and having that archival information has not been needed for our users. Statistics from longitudinal studies are more important to our users than the archival information. Users are not segmenting multiple objects in a given volume. Itās always the same type of object. They arenāt building up an atlas.
This application also suggest to me the ability to incorporate, import, or subset multiple terminologies. For instance, a base anatomy or tissue material terminology that is overlaid by a custom specialized terminology.
Additional note about something Iāve done which may honestly be worse than not coding a terminology to a color which is Iāll code the wrong terminology from the terminology list just because it is quick and simple for me to use its color.
You can already import and edit multiple terminologies, but you need to edit text (json) files, which is probably not convenient enough. What do you mean by āoverlaid by a custom specialized terminologyā? Being able to select terms from multiple terminologies?
Hi, James.
As youāve invited my comment I can let you know my current practice, whilst you keep in mind that it may not be optimal and may not represent the majority of usersā¦
Foremost I care about the colours of the individual segments of a segmentation, and in this there are a few priorities:
To readily distinguish one segment from another. Here I would be more-or-less in line with your earlier statement (quoted below).
To provide distinction between a segment and another āoverlaidā object. In the 3D viewing port that would most commonly be a 3D rendering of the volume, but could also be an object imported into the Data structure from an STL file (e.g. somebody elseās earlier attempt at a segmentation of the same feature); also control points from the Markups module (mostly Fiducial markers). In the 2D slice viewers of course it would be the DICOM series (which are typically CT scans, which I view in greyscale).
To allow clear visualisation of surface morphology in the 3D view: some colours seem to me to have more obvious shadows.
Besides all of that, I might try to organise colours thematically: letās say red, orange and pink for objects imported as STLs, and blue, cyan and green for segments.
I donāt use terminologies, as
the audience is generally me;
I donāt segment lots of different types of features (Iām not trying to build an atlas);
I am mainly interested in segmenting one main type of feature (brain aneurysms, with a shortish length of connected arteries).
Furthermore ā and this may not be an obvious workflow, so I describe it here in some detail ā I may have multiple segments for one single feature.
For example (1), I might ā¦
create a preliminary segment based on thresholding;
make a copy of that segment and smooth it by one method;
make a further copy of the original segment and smooth it by a different method; and
compare the three segments to identify the impact of each smoothing effect and choose the ābestā one.
For example (2), I might ā¦
create a preliminary segment;
make a copy of that segment and use the Scissors, Erase, Paint and/or Draw effects to āmanuallyā add/remove voxels;
I can compare the two segments to see the impact of my changes; and
if at some later stage I decide that the changes werenāt quite right, then the preliminary segment is still available to try again.
For example (3), I might ā¦
segment the feature using a Threshold effect;
segment the same feature (from scratch) using a Grow from seeds effect;
compare the two segments, and choose the ābestā one to export.
I really appreciate the discussion here. For my purposes, I am often trying to display multiple types of information so that it is best communicated through a set of snapshots. This communication could be aided by using a consistent set of colors in a consistent terminology (which I have not tried to develop yet), so I appreciate that such a capability is present in Slicer. However I am also very often trying to choose colors for visual distinguishability, and since it is not easy to chose a set of ~25-30 colors which are all clearly distinct from each other and clearly distinct from grayscale and clearly distinct from the background of the 3D view, it is not uncommon for me to be trying out different colors for a particular structure or grouping of structures. The current color selection interface is very tedious for trying out colors just to see how they look. For example, to change the color for a MarkupsCurveNode in a recent preview release, I have to
double-click on the color block in a hierarchy; this brings up a window titled Slicer and lists terminology terms
in this window I have to click on the color block again; this brings up a window titled Select Color and has a color node selector and a list of terminology terms. I usually just want to use a basic color (because itās not a bad set of colors and this makes it easier to choose the same color again in the future than specifying a custom color).
to get to Basic colors, I have to click on the tab titled Basic
Then I finally get to select my basic color (one more click)
and click OK (this returns me to the terminology/color selection window titled Slicer)
then I need to click Select, and finally the color I wanted to try out is applied to the curve
That is 7 clicks to try out a color. If I donāt like how that looks, I have to go through another 7 clicks to try a different color. If I want to try out 4 basic colors, thatās 28 clicks.
Of these 7, the last two clicks seem unnecessary. Why not apply the selected color immediately, while the color selection window is still open? That way, while it would take a few clicks to get to whatever color selection method the user prefers, once reached, one could see the effect of the chosen color before leaving the window.
Something in the custom app that we do is we utilize this list of 20 distinctive colors (List of 20 Simple, Distinct Colors | Sasha Trubetskoy). We order it based on accessibility so the colors that are difficult for those who are color blind are chosen toward the end.
I use colorbrewer when I need to make sure I choose distinct colors. But unfortunately 25-30 distinct colors are difficult to find whatever you do (either the transition between them will be too gradual or you will be including colors that are not color-blind safe). But for smaller subset (I think it goes up to 12), it worked fine for me. I believe the top number is sort of arbitrary, since it is a cartography tool, I donāt think they need lots of classes like we do.
Thanks @muratmaga and @jamesobutler, Iāve used both of those very helpful resources before to come up with my own colormaps for the 17 or 20 ventricular segments used in nuclear medicine cardiac scans. In the current primary application I am using/developing, there are typically 15-20 stereotactic EEG electrodes (ideally each with their own easily distinguishable color, represented visually by markups curves or by modeled cylinders), plus a color to show which one is currently selected, plus a variety of possible other layers of data including annotations of prior resection cavities, fMRI motor (two sides) or language activation areas, and potentially also overlaid on the multicolored FreeSurfer parcellation. In my experience, itās no problem to get to 10-12 colors which show up well against all shades of grayscale and are all clearly distinguishable from one another. 30 is clearly impossible, so in complex cases I find that some color curation is necessary, especially because Iād probably like to use the ābestā colors for the most important information, which can vary from case to case.
This is a helpful discussion. It could make sense to write some modules to customize the color selection as a bulk operation based on high level constraints.
Also as food for thought Iāll point out that we havenāt exposed these rendering options but there are a ton of ways we could increase visual distinctiveness in 2D and 3D rather than just base color.
So it seems that wanting distinct colours may be a common wish/requirement.
I had another look back at the existing Basic colour swatches in Slicer.
It may be worth reviewing this to see if a set of āoptimally distinctā colours can be provided.
Also, I would prefer to arrange the Basic colours somehow by hue/saturation/value. Currently there are three fully-saturated red colours (hue=0) of differing value that are not grouped, three fully-saturated green colours (hue=20) of differing value that are not grouped, and three top-valued pink colours (hue=300) of differing saturation that are not grouped, for example.
By way of comparison, my version of Microsoft Word presents 127 standard colour swatches (in websafe R/G/B steps of 00, 33, 66, 99, CC, & FF), including white, plus 15 grey swatches, plus white (again) and black. All are arranged in a systematic way.
With regard to Slicer, 127 is of course too many colours to be distinct, but using all RGB combinations of R/G/B steps of 00, 7F (or 80), & FF would yield 3Ā³=27 colours (including black, white and medium-grey). Maybe not optimally distinct, of course, but perhaps not too bad, and having the advantages of being systematic and simple (a.k.a. āBasicā?). There are very few examples of this set of 27 colours presented online: here is one, under āPriority 3 (27/27 named) and Priority 2 (8/8 named)ā.
Thereās also an interesting discussion of optimising visual distinctiveness of colours on Stack Overflow.
In any case, it does seem worth considering to include one or more greys among the Basic colours (black and white are already there).
I have done this too, once or twice, but I found the colours in the terminology list seemed more muted, and less distinct. Lots of reddish brown, at any rate, meaning lots of scrolling to find a āniceā colour.
