Problem report for Slicer 4.11.0-2020-06-30 linux-amd64:
When I export a set of segments to a labelmap, if I don’t select a reference volume under the advanced tab of the ‘export/import models and labelmaps’ portion of the ‘Segmentations’ module, the latest version of Slicer crops the volume of the labelmap instead of keeping the volume of the label map the same as the volume used to create the segments/ labelmap.
Previous versions kept the dimensions of exported labelmaps the same as the volumes used to create segmentations. Its there any way to get the default to keep the volume dimensions the same when exporting labelmaps?
I cannot reproduce this. Maybe you have opened a segmentation file that was created with an older Slicer version? If not, then please give step-by-step instructions of what you did (start slicer, load X sample data set, go to Segment Editor module, …).
Before the June 30th preview version of slicer, my work flow was:
Start slicer. Load a segment (.seg.nrrd) and corresponding volume data (.nrrd). In the Segmentations module expand the ‘Export/import models and labelmaps’, select Export for operation and Labelmap for output type and create a new node. This would give me a labelmap with the same dimensions as the corresponding volume data with the label of 0 for any areas that there were no labels.
As of the June 30th preview, if I follow this same protocol the output is a labelmap that is cropped to only include the space immediately surrounding the labels, so a different dimension than the corresponding volume.
Murat did find a work around that if when I export the labelmap, under the advanced options I can choose a ‘reference volume’. When I do this I do export labelmaps with the same volumes as the original volumes.
Also I believe the segment files (.seg.nrrd) were created using the 6/15 preview
Thank you, these instructions were helpful. I was able to reproduce the behavior: if you load a saved segmentation and then export it to labelmap node then the minimum necessary extent is used.
While the current behavior is correct (and optimizes memory usage), I see how it can be unexpected for users and agree that it would be more convenient if the original extent would be used by default, mainly for better compatibility with software that ignores physical space information.
I’ve changed the default behavior now, so in tomorrow’s Slicer Preview Release the export will work as you expect .
3 Likes