Exporting a segmentation paired to a custom colortable

Hi,
I’ve been reading the threads about naming/numbering and the colormaps for segmentations:
Export Segmentation as Labeled LabelMap
Copying segment names/colors from one segmentation to another

I am not sure to be able to export the labels according to the colortable properly: similar to @apparrilla, I have a colortable that has e.g. 37 (0, 36) consecutive labels. I am manually segmenting structures e.g. 29 and 35. When exporting them, if I pick the colortable that I am using, they are numbered as 37, 38 (besides the background, 0), which I would say is not expected already.

Additionally, if I try to load the exported NIfTI file into Slicer and choose the colortable at issue, they get colored with the RGBA values corresponding to label IDs 1 and 2 in the original colortable.

If I load a segmentation file (automatically generated with another tool) that contains 35 labels (0, 34), and if I load my 37 consecutive label table and set it as the color node for the segmentation to be loaded, they are colored and named following the colortable, as expected.

I’m wondering what step I am missing in all this to be unable to export labels properly.

Thanks.

Sharing the color table and a labelmap/segmentation would probably help. Without those it is hard to tell what you might be doing wrong or missing.

@lassoan I can replicate this behavior on latest stable.

  1. I created two segments on MRHead called left_ventricle_chamber and right_cerebellar_primordium
  2. Used this color table during the export: MD_E15/KOMP2.ctbl at main · SlicerMorph/MD_E15 · GitHub

As opposed to being assigned to indices 44 and 49 as expected, they were assigned 51 and 52.

Thanks for the quick reply @muratmaga.

Sharing the color table and a labelmap/segmentation would probably help. Without those it is hard to tell what you might be doing wrong or missing.

You’re right. Not ideal to try to guess without data, but I chose not upload the data somewhere due to various constraints. Apologies.

@lassoan I can replicate this behavior on latest stable.
As opposed to being assigned to indices 44 and 49 as expected, they were assigned 51 and 52.

OK. So looks like an undesired/unexpected behavior was introduced at some point. Forgot to tell that I am using version 5.2.2.

I’ve tested Slicer-5.6.2 and everything works well: if a segment name matches a color name in the chosen table, then the label value in the exported labelmap volume is the color index.

What confused @muratmaga was that internally in color table files, space character is stored as underscore (probably for easier parsing). In Colors module you can see the actual color names that must match the segment names:

We know that this ctbl file format is inadequate and we should phase it out - see Improve color table node format · Issue #7593 · Slicer/Slicer · GitHub

It all works well in the Latest Slicer Stable Release, so please use that. I don’t think it was broken in Slicer-5.2.1, too, but I have not tested it now. Most likely your segment names don’t match the color names that you selected for exporting to labelmap. But if you think something else is going on then please provide instructions and data. You can use any of the Slicer sample data sets.


All this color table based matching is very fragile, even a single character mistyping may cause segments not to pair up with labels. Also, label values cannot be standardized between multiple projects. Therefore, I would recommend to move towards identifying segment content using standard terminology codes. They are global identifiers that can be shared between projects and they allow using different name variants and spelling for segment names.

1 Like

Thanks for giving this a try @lassoan.

I made sure that I am using exactly the names in my colortable, and have simplified it to the following:

# Color table file my_colortable.txt
# 4 values
0 Background 0 0 0 0
1 Left 231 255 0 255
2 Right 111 231 0 255
3 New_I_name 0 230 92 255
4 Another_I_New_Name 30 30 102 255

As shown in the screenshots below, I am choosing the colortable at issue (have loaded different versions, thus the name my_colortable_2 displayed), and I am getting the same result as yesterday.

Drawing:

Exportation:

Loading the exported file:

Any testing image will serve to demonstrate this.

Upgrading to a newer Slicer version is unfortunately not an option at this time for me (an extension I use has been reported to have issues in more recent versions).

As I wrote above, you need to use the color names that show up in Colors module, which is not exactly what is stored internally in the color table file (due to spaces are replaced by underscores). Your screenshots show that you use underscore in the segment names, so the names don’t match. We’ll switch to a new color table file format soon, which does not have this confusing behavior.

It is extremely important to keep up your extensions working with latest Slicer version. Which extensions users having problems with?

I confirm that everything works as expected (i.e., labelmaps are exported with correct indices) when you replace underscore (_) with space. I tested it 5.6.2. If 5.2.2 doesn’t export it correctly for you (with the replacement), you can install 5.6.2 and export in there.

I am not sure how this will fix the conversion to the labelmap though. Labelmaps are what goes into the ML training, and they need to have indices. So we will always need some sort of lookup between segment labels and labelmap indices, regardless if the segment labels comes from a standardized terminology. Or am I overlooking something?

10 posts were split to a new topic: Create standard terminology for new segmentation project

OK, thanks Andrass. Thanks Murat as well for the valuable input.

you need to use the color names that show up in Colors module, which is not exactly what is stored internally in the color table file (due to spaces are replaced by underscores).

Indeed, underscores are replaced by whitespaces, and using such names solves the issue. Have just tested.

It is extremely important to keep up your extensions working with latest Slicer version. Which extensions users having problems with?

I am aware of this. Some SlicerDMRI features were reported as having issues with the most recent Slicer versions towards the end of 2023.

BTW, you may want to transfer the exchange about the best possibilities going forward about color tables to a dedicated thread so that you can consolidate the discussion.