How to unset default 'compress' option during save

You can enable/disable compression using storage node’s SetUseCompression method.

Thank you. Based on the example, this works:

#set the default 3D model format to PLY (instead of VTK)
defaultModelStorageNode = slicer.vtkMRMLModelStorageNode()
#to turn off compression for the models

But I couldn’t figure out how to use the provided Change file type for saving for all volumes (with already existing storage nodes) example to work with fresh scenes with no volume loaded.

defaultVolumeNode = slicer.vtkMRMLScalarVolumeNode()

fails with AttributeError: ‘vtkCommonCorePython.vtkMRMLScalarVolumeNode’ object has no attribute ‘SetDefaultWriteFileExtension’

You need to change the default volume storage node (not the default volume node).

Thanks, but looks like I need more guidance…

defaultStorageNode = slicer.vtkMRMLStorageNode()

fails with TypeError: this is an abstract class and cannot be instantiated

and I can’t locate a vtkMRMLVolumeStorageNode() (or rather how/where to find it).

Here’s an example:

#set the default volume storage to not compress by default
defaultVolumeStorageNode = slicer.vtkMRMLSegmentationStorageNode()
slicer.mrmlScene.AddDefaultNode(defaultVolumeStorageNode)"Segmentation nodes will be stored uncompressed 

This is also in theScript Repository now.

This came up in another thread recently:

We could potentially get a big performance boost at minimal file size cost by changing the default gz compression level to 1. In some small-scale tests I did a few months ago, there was a major time cost between high and low settings, for only a tiny compression improvement (e.g. 90-> 26 MB at level 9 in 34s, vs 90->27 MB at level 1 in <1s). This was only a small test on a few brain MR datasets, but it seems reasonable.

Using a low compression level would make a lot of sense, as one of the main reasons I would keep compression enabled is to deflate blank voxels around images that have a non-rectangular shape.

Is there an API to change compression level in ITK IO classes?

Looks like only for a few specific formats (MINC, PNG). For NRRD we can set it in teem directly.

@muratmaga tomorrow’s nightly build will have this commit which changes the default nrrd compression to ‘low’ so it should be faster and still pretty good compression. Let us know how it works in your use cases.

downloading right now!

So, I don’t need to do anything to enable this right? I am seeing about 10% gain over the behavior in 4.8.1 for a dataset about 1.8GB. (took 40 seconds on 4.8.1 to save, 36 second wtth todays nightly). Perhaps gains are more for larger dataset. I will try with a larger one.

Also, there is problem with file renaming at the save dialog box. Whatever I type, it reverts to the original file name when I click save.

Thanks for testing @muratmaga - what’s the original size of the data and maybe @ihnorton can comment if that’s in line with his expectations.

Regarding the save dialog it works for me here on my local build (mac). I can change the name of the file in the save dialog and the file is saved under that name. But the node name is slicer is unchanged. If I change the name in slicer then the suggested file name is updated next time I go into the save dialog.

This is what I see when I hit save:


I click the checkbox and type and alternate name (I don’t want to overwrite).

The moment I click save, this appears, and note that name has reverted

In fact name gets reverted to the original the moment I unfocus from the text field.

Ah - I think I see - here you are changing the extension to ‘.save’ and so it changes back. What if you change it to ‘testing.nrrd’ ?

Yep, it doesn’t do if I don’t use a ‘.’ to separate words.
But 4.8.1 happily accepted multiple '.'s in a file name, and appended its proper extension.
Is this change intentional?

I don’t think it’s intentional, but it may have be related to the use of compound names like file.seg.nrrd for segmentations. @lassoan any comments?

But I find it I type something like it works as expected so if there’s a reason it needs to be like this the workaround doesn’t seem too bad (granted it’s another thing to learn so it’s not ideal).

Another user recently had problems (see Save scene with written name) regarding the file name being reverted without their knowledge. The name isn’t reverted until the file name field is no longer being actively edited. It can be confusing when going from actively editing to pressing the save button. If the file doesn’t already exist, it will use the reverted name which the user won’t know and the dialog immediately closes. At least here @muratmaga was able to notice that it wasn’t using the file name “” because an “already exists” warning appeared for the reverted file name.

I agree this can potentially frustrate a lot of new people. The change is too quick to notice if you hit save directly, and it there is no older version it will get written with a different file name than you intended.

Name of the column is “file name” because it actually contains the file name, including extension. You cannot enter a filename with an invalid extension, such as or I understand that you would expect to edit the file base name there. Maybe adding a “show extension” checkbox would help (that would switch between showing the file base name and complete file name)?

I don’t like the current behavior of resetting file name based on node name. Unfortunately, if we don’t do it then it may lead to other problems: you may not be able to find your data easily, may mix up data sets because you only renamed the node in the scene but not the filename. I don’t know if there is an easy solution to this.

The use case is someone importing a new stack, and then saving it as an nrrd, where they may want to rename the imported dataset as more appropriate for their workflow. If you are not going to let them do this at the save time, then I think actually it will be better to make the save as filename box not editable at all, and force them to make the change at the node level using data or subject hierarchy. As it is, it is confusing…