Util for creating a `.seg.nrrd` based on existing nrrd + segment names

[kretes]

Maybe that's something obvious but what I just needed was a simple tool to name the segments in nrrd.

It turned out that this works to create a valid seg.nrrd for Slicer:

from pathlib import Path
import nrrd

def add_segments(nrrd_data, nrrd_header, segment_names):
    assert len(segment_names) == nrrd_data.shape[0]
    for segment_index, segment_name in enumerate(segment_names):
        prefix = "Segment{0}_".format(segment_index)
        nrrd_header[prefix + "ID"]=str(segment_index)
        nrrd_header[prefix + "Name"]=segment_name
        nrrd_header[prefix + "ColorAutoGenerated"]=1
        nrrd_header[prefix + "LabelValue"]=1
        nrrd_header[prefix + "Layer"]=segment_index
    return nrrd_header

def add_segments_to_nrrd(nrrd_input_path, segment_names):
    nrrd_input_path = Path(nrrd_input_path)
    nrrd_output_path = nrrd_input_path.with_suffix(".seg.nrrd")

    nrrd_data, nrrd_header = nrrd.read(nrrd_input_path)
    new_header = add_segments(nrrd_data, nrrd_header, segment_names)
    with open(nrrd_output_path, "wb") as f:
        nrrd.write(f, nrrd_data, new_header)

Leaving it here for others finding the same need. Would this be something worth adding in this or extended way to slicerio ?

[lassoan]

Thanks for sharing this code. We definitely need to add functions for creating .seg.nrrd files from scratch. Your code looks nice, but it would need to be extended with at least these two features before I would promote it as the way of creating segmentations:

• Use shared labelmap (store many non-overlapping segments in a single layer), because if you have more than 10-20 segments then the overhead of storing each segment in a separate 3D volume becomes intolerable. For example if you store a brain atlas (200+ structures) or TotalSegmentator results (100+ structures) then loading and initializing all the segments typically takes minutes, while the same takes a fraction of a second if you use a single shared labelmap.
  • The implementation should be able to take shared labelmaps containing non-overlapping segments and should be able to split and merge segments so that you can switch between per-segment and shared labelmaps.
• Use terminologies, because segment name is too ambiguous. For example, "lung", "lungs", "Lung", "Lungs", "left lung", "Left Lung", "Left lung" are all valid choices yet arbitrarily choosing between them lead to inconsistency between different data sets. If you want to reuse the same data set in multiple projects then I don't see any other option than using standard terminology.
  • The implementation should make it very easy to look up teminology by name (and auto-fix small issues such as capitalization and report error when there is an ambiguity). We can include dicitionaries from DCMQI and maybe TA2.

[kretes]

Thanks for the reply!

Shared labelmap makes sense, I will switch to this style for my needs as well. I will post the updated version that will let the user control this behaviour.

Terminologies seems like something that should be done on top of this util. It just defines the segment_names. In my use case segment nnames are dynamic, as I generate seg.nrrd to understand predictions from a nodule detection model. So I put there some metadata like model's confidence.

[lassoan]

It is better not to pollute the segment name with additional metadata. You can put extra information in segment tags (key/value pairs).

These tags are easily accessible in Slicer for Python scripts.

Currently, the tags are only shown in the Data module, but we could also think about making it more easily accessible (maybe show selected tag values in additional columns in the segment list?). In the meantime, you can write a short Python script to retrieve the tags and display them somewhere.

[lassoan]

This feature is available now - see example here: https://github.com/lassoan/slicerio?tab=readme-ov-file#create-segmentation-file-from-numpy-array