Page MenuHomePhabricator

Multilabel color map colors are not very nice
Closed, ResolvedPublic

Assigned To
Authored By
isensee
May 20 2021, 9:19 AM
Referenced Files
F2525497: palette_sorted.png
Mar 30 2022, 11:35 AM
F2524973: palette.png
Mar 28 2022, 9:23 PM
F2524969: palette.png
Mar 28 2022, 9:10 PM
F2524953: IPnOgeM.png
Mar 28 2022, 8:32 PM
F2524861: image.png
Mar 28 2022, 3:16 PM
F2502444: mitk_colors_t.png
Feb 10 2022, 3:47 PM
F2502446: MultiLabel lookup table.png
Feb 10 2022, 3:47 PM
F2274746: tmp.png
May 20 2021, 9:43 AM

Description

Recently upgraded to

image.png (19×531 px, 7 KB)

(Ubuntu 18.04)

Now when I load segmentations and set the multilabel color map MITK correctly sets a unique color for each integer in the segmentation. Nice! (That didn't work before).
However, I can no longer change the colors in the level window slider and the default colors are not very nice, example:

image.png (501×1 px, 125 KB)

Here the vein (coming from the kidneys) has almost the same color as the kidneys. Both are very yellow and it is difficult to distinguish them.

a) it would be great to still have the option of somehow changing colors so that in situation like this colors can be adapted
b) it would be even more fantastic to get better colors by default. For example one should not allow the same color in different shades (intense yellow, fading yellow, dark yellow). I will try to come up with python code to demonstrate what I mean.

Best,

Fabian

Revisions and Commits

rMITK MITK
Restricted Differential Revision

Event Timeline

import numpy as np
import colorsys
from skimage import io

if __name__ == "__main__":
    image = np.zeros((1, 256, 3))
    for i in range(256):
        color = np.array(colorsys.hsv_to_rgb(i / 256, 1, 0.8))
        image[:, i, :] = np.tile(color, (1, 1))
    io.imsave('tmp.png', (image * 255).astype(np.uint8))

    # sample X colors:
    x = 16  # must be a square if an int, examples: 16, 25, 36 etc
    colors = np.array([colorsys.hsv_to_rgb(i, 1, 0.8) for i in np.linspace(0, 1, x + 1)][:-1])
    colors = colors.reshape((int(x**0.5), int(x**0.5), 3))
    io.imsave('samples.png', (colors * 255).astype(np.uint8))

tmp.png:

tmp.png (1×256 px, 133 B)

samples.png:

image.png (538×542 px, 9 KB)

Still has rather similar greens but you get what I mean :-)

(yes the python code is inefficient. This is a proof of concept and not representative of the programmers abilities :-D )

kislinsk added a subscriber: kislinsk.

I think I once looked into this specific issue and it turned out that your label values had quite some gaps between there values resulting in similar neighboring colors "by accident". Consecutive label values would be quite distinguishable. I am not sure if at least the first x colors follow a certain standard or not. This should be checked first before changing the colors.

The labels in my example are consecutive integers. And even if they weren't the color mapping should skip unused integer values. Use equivalent of np.unique(segmentation) to determine used labels and set the map accordingly.

This issue persists in snapshot 2021-10-01 and is a real dealbreaker. I don't agree with the low priority @kislinsk

I understand that multilabel is the way to go in the future but it suffers from exactly the same problem and having to change that manually for every label in for every segmentation is it very user-unfriendly. I like to use MITK to inspect segmentation results so I need to be able to view many different segmentations in quick succession. That is only possible if MITK provides good default colors.

kalali raised the priority of this task from Low to Needs Triage.Feb 10 2022, 3:47 PM
kalali added a subscriber: kalali.

I stumbled upon this since I want to automatically assign label colors to new labels. I use the Multilabel lookuptable (see https://phabricator.mitk.org/source/mitk/browse/develop/Modules/Core/src/DataManagement/mitkLookupTable.cpp$527) and the values are not working to distinguish neighboring labels / indices sufficiently.

The first 25 label colors are defined here (https://phabricator.mitk.org/source/mitk/browse/develop/Modules/Core/include/Colortables/Multilabel.h) and they look like this (from top left to bottom right):

MultiLabel lookup table.png (200×200 px, 578 B)

There are even some equal colors, e.g. color 12 and 18 or color 19 and 23.

In MITK this looks like this:

mitk_colors_t.png (882×825 px, 25 KB)

I suggest to change the lookuptable / colormap. What we want is a qualitative color map, e.g.

Question remains:
How do we handle labels with an index larger than 12 (24, 25). In the current code we repeat some colors for every 12th label (and btw. also use colors that have already been used before in the first 25 labels).

kislinsk triaged this task as Normal priority.Feb 16 2022, 5:40 PM

The problem was mentioned again in the tested checklists:

  • image.png (123×978 px, 13 KB)

I procrastinated on the colors tonight for quite some time and finally found something that really stood out - the standard distinguishable color palettes of R:

IPnOgeM.png (480×672 px, 3 KB)

https://stackoverflow.com/questions/50321000/r-colors-many-distinctive-colors-that-are-still-pretty

Kelly is nice because it is not overly saturated as most other palettes, but I think the most useful is indeed glasbey, when the two black-ish and one grey-ish colors are removed for our context. Red and magenta both appears pretty similar twice. Also, the colors should be a reordered a little bit and for the sake of compatibility/expectations start with red. More or less the same for polychrome but there we would also need to get rid of more grey colors.

This is my shot at it mainly based on the palettes above with extra effort regarding neighboring color contrasts (top-left to bottom-right). But it is impossible to get 25 perfectly distinguishable colors. Also I took into account that the human eye has the highest sensitivity in the green spectrum.

palette.png (500×500 px, 2 KB)

kislinsk claimed this task.

Reordered palette from above to see similar colors next to each other to simulate the worst case:

palette_sorted.png (698×858 px, 4 KB)

We decided in the group 5 meeting today, that we go for it. It is merged into the current release branch.

This comment was removed by kalali.