Hello everyone.
I am comparing two structures of nii.gz image by using SegmentComparison. However, I cannot select the inputs (red circle), as attached, there is no segments to select.
Thanks.
You’ll need to create a segmentation from the volume.
Import or convert the nii.gz to a labelmap node as described here:
Then, in the Segmentations module, import the labelmap node to a Segmentation. The option should be under the “Export/import models and labelmaps” section.
Many thanks Kyle…I got it
In most recent Slicer Preview Release (since 1-2 days ago) you can load a nrrd labelmap volume file directly as a Segmentation node (select “Segmentation” in description column in “Add data” dialog).
@vietlebao is there a specific reason you use nifti (nii.gz) file format instead of nrrd?
@Sunderlandkyl could you have a look into supporting reading 3D nii.gz files directly as segmentation nodes? No need to allow saving into nifti (as adding custom metadata to nifti files is very complicated).
2 Likes
I have done many times [Load nifti / more options / label / Segmentations / create / import from labelmap].
+1 to the option of reading NIfTI as Segmentation nodes!
Do you have any reason to use nifti format for storing segmentation?
Importing a plain labelmap volume is fine, but it is complicated to save custom metadata in a nifti file, so we probably won’t support saving segmentation into nifti files anytime soon (unless there is a commonly used standard emerges that allows storage of essential segmentation metadata, such as segment names and colors).
Nothing specific. The labs where I’ve worked only use nifti, maybe because I’ve mostly done neuroimage. I’ve never seen anyone using nrrd, just myself whenever I’m handling Slicer segmentations.
Usually, I just save any segmentations as label maps, so that’s ok.
It’s true, this is very common practice. The problem is that it’s also very common. for people to use a variety of ad hoc methods to track segment numbers, colors, etc. and it’s held the field back IMO. I think that’s why there’s a big push for bids, and perhaps it’s time for a SlicerBIDS extension.
1 Like
I like that anybody can easily create a BIDS data set just by converting DICOM to nifti and adding text files to describe them. This is what most people end up doing before starting to analyze their data anyway and using common conventions for this helps.
However, simplicity stops here. BIDS standard is already probably well over hundred of printed pages long and in BIDS you cannot even store a CT image in standard way yet (it is not in the standard, they are looking for volunteers to work on the extension specification). BIDS extensions page contain links to hundreds of pages of additional documentation awaiting to be added to the standard. To me, BIDS specification seem just as long and complex as corresponding sections in the DICOM standard. BIDS usage of filenames and folders to group and cross-reference information is nice and simple and suitable for certain use cases, but DICOM’s UID-based system is much more robust and flexible. You can already see many cracks showing in BIDS 2.0 ideas document caused by fixed folder structure and others.
Overall, BIDS is a nice format to follow for brain imaging researchers, but it does not seem to be scalable to a general medical image computing standard. It would be nice to somehow channel the enthusiasm about BIDS to improve DICOM standard and toolkits to make DICOM directly usable for research.
1 Like
Ah, well, of course many people know that my preference is DICOM too!
My point about a SlicerBIDS is that if there is a community who uses it, then some of the developers in that community might also be willing to promote interoperability with tools that rely on BIDS.
2 Likes