Older Scenes and Specimens Loading Incorrectly

Hello Slicer Community,

I have recently encountered a problem loading some older specimens and project files that I worked on back in 2020 using Slicer 4.10.2. Originally, the scenes would appear like so, with the specimen and the masks overlapping properly:

When I tried to open these files again, in Slicer 4.10.2, and in several other versions of Slicer, including Slicer 4.11.0-2020-09-08, Slicer 4.11.2021-02-26, and Slicer 5.03, the scene appears distorted in various ways.

For example, with the same specimen now opened in Slicer 4.10.2:

And opened in Slicer 5.0.3:

When I opened the segmentation file for one of these specimens in Slicer 5.0.3, I got the following error message:

- Error: Loading D:/Scans/Phrynosoma Ingroup Scans/Phrynosoma cornutum/Segmentation/2020-08-11-Scene.mrml - ERROR: In D:\D\S\S-0\Libs\MRML\Core\vtkMRMLStorableNode.cxx, line 322

vtkMRMLVolumePropertyNode (000001AAC64937D0): vtkMRMLStorableNode::UpdateScene failed: Failed to read node VolumeProperty (vtkMRMLVolumePropertyNode1) using storage node vtkMRMLVolumePropertyStorageNode1.

- Error: Loading D:/Scans/Phrynosoma Ingroup Scans/Phrynosoma cornutum/Segmentation/2020-08-11-Scene.mrml - ERROR: In D:\D\S\S-0\Libs\MRML\Core\vtkMRMLStorableNode.cxx, line 322

vtkMRMLColorTableNode (000001AAC9F07E40): vtkMRMLStorableNode::UpdateScene failed: Failed to read node Segmentation-label_ColorTable (vtkMRMLColorTableNode1) using storage node vtkMRMLColorTableStorageNode22.

- Loading D:/Scans/Phrynosoma Ingroup Scans/Phrynosoma cornutum/Segmentation/2020-08-11-Scene.mrml - These extensions were installed when the scene was saved but not installed now: . These extensions may be required for successful loading of the scene.

This is the closest hint I’ve gotten to diagnosing the cause, but I don’t have the technical expertise to know what would be causing these issues and generating this particular error message. This is a fairly distressing situation, though, because I have about 13 specimens that I put a lot of work into preparing that seem to be affected by this issue, and I really need to be able to access the segmentation project files in their original forms in order to make further progress with them. Any suggestions or fixes for this situation would be very much appreciated!

Can you share one of your datasets?

it shouldn’t be difficult to fix, but we need to see the where the problem is coming from.

I attempted to share one of the data sets as a compressed .rar file, but the upload function won’t work since that is not an approved file type. How would I go about sharing it here on the forum?

You need to post it somewhere on the cloud and share the link

Here’s a Google Drive link:


Let me know if you have difficulty accessing it.

The image spacing of the volume in the Z direction looks incorrect: 0.0074 x 0.0074 x 1.000.

I can get it pretty close to looking correct-ish by setting the Z spacing to 0.056 or so, but that’s still not quite right.

I don’t think the missing color table or mis-matched extension setups would cause this. The volume is also saved with this spacing, so I’m not sure how this worked originally. Basically, it looks like the Z spacing of the segmentation and the volume don’t match.

The problem is that the image was saved in TIFF format. This file format cannot store image orientation and Z spacing in standard tags, therefore the information is lost when it is saved. If you load the image again from the original source (maybe a DICOM files from MorphoSource) and save as .nrrd format then everything should work well. If you don’t have the source files anymore then you may need to experiment with the spacing and alignment.

TIFF format is not a 3D file format and we cannot fix its limitations but Slicer should display a warning when somebody attempts to use this file format for saving a 3D image. I’ve aded an issue to display a warning message:

So we have that issue in ImageStacks as well. If someone imports a tiff sequence. and then try to save the imported volume. The default format is shown as TIFF. This is not the case with other formats (PNG/JPG/BMP etc).

It is also the same behavior if one uses Slicer’s regular Add Data menu and import a TIFF sequence. It keeps the format as TIFF. I suggest that behavior needs to changed on the application side. Users are not always knowledgeable about data formats and issues, we should offer to save in the most reliable format (NRRD). If the the user has a specific reason to keep it TIFF, then they can manually override that.

Thank you for clarifying this issue! I didn’t know that it was because of the data format, though I will definitely know to be cognizant of this in the future. That said, reloading the original TIFF stack via ImageStacks with the correct X, Y, and Z spacing allowed me to realign the specimen data with the original masks that I had prepared. The masking threshold didn’t seem to be saved, though, so for others that may encounter this issue in the future, reloading the image stack with the original spacing and sampling parameters, deleting the original volume, selecting the new volume, and adjusting the masking threshold to approximately match the area covered by the original masks worked to get me to the point where I could start applying edits to the original masks. Hopefully others find this helpful!

That said, when I got to save revised versions of these projects, how would I save the projects as .nrrd format files so that I don’t repeat this issue? Let me know, and thank you again!

Yes, when the imported volume is saved as a TIFF file, all the spacing settings you entered during the import is lost. it is always better to save the volumes as NRRD to avoid that issue.

If you want to reconstitute your original scene without having to repear the steps, load each dataset (volume and segmentation) individually (not from the mrml file). Go to the Volumes module, edit the correct spacing of the volume, and things should line up. Then make sure you save the edit volume as a NRRD file.

I agree, in addition to the warning we should set the default file format to nrrd for 3D images. I’ve added a comment to the issue.

I had similar problem but with nrrd files. When I opened segmentation nrrd file, it didn’t overlap the dicom set, yet it was offset on the side.

If you can share data that replicates this issue, with the steps to recreate it based on specific versions of Slicer it could help track down what’s different. Any changes in Slicer behavior are intended to be backwards compatible with previous scene files. If you didn’t use scene files then it’s possible that legacy formats like stl load incorrectly because the coordinate systems are not defined by default (and weren’t for files created by older versions of Slicer).