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.
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:
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.
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.
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?
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.