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 testing.save.nrrd 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 “testing.save” 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 volume.abc or volume.nrrd.abc. 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…
You may be right. Currently, Save dialog in Slicer serves two purposes: Save and Export. It could help if these two functions would be more clearly separated (allow saving with a single click, without asking anything; use the current Save dialog for export only).
At least in Windows, the native file dialog has a “File name” entry, but it refers to the basename and “Save as type” is for defining the extension. I personally find it unusual to have to type the extension in a “File name” cell. It seems redundant when “File format” is defined next to it.
In general, file extensions are shown in native file dialogs:
You have an option in Windows explorer to hide them (if you disable “File extensions” option), but even then they can only be hidden for files that have an extension that is associated with an application.
From what I’ve read and experienced, file extensions are hidden by default in native file dialogs and users can change a setting to then show them. In recent Windows and Mac the setting is written something like “Show extensions” with a checkbox, though at least in Windows 7 in an advanced area it is referred as the opposite as “Hide extensions” and that is checked.
- For Windows, extensions are hidden in Explorer by default (see Article telling users how to show them.)
- For macOS, extensions are hidden in Finder by default (see Article telling users how to show them.)
I think it would be best for Slicer to expect that users are familiar using the defaults of the major OS platforms. I would be in favor of Slicer’s save dialog not requiring the extension to be specified by default and letting the autoselection of File Format to be used as the extension. The Slicer save dialog could have a user setting to then show extensions in the file name and that would reimplement the option that is present for native file dialogs on the major OS platforms.
Native dialogs only hide known file extensions, while most medical image computing file formats that Slicer uses (nrrd, nii, mha, fcsv, …) are not known. So, they so show up regardless you check/uncheck “File extensions” option.
Regardless, I agree that having a “File extensions” checkbox (similarly to Explorer) would be useful as it could make things look more familiar for some users.
Ok, I understand now. You are correct the typical file types used won’t be known extensions. Is there a reason for the redundancy of showing the extension in the file name and having it shown in the column directly to the right of it? When the file format is changed it automatically changes the extension in the file name cell, but if you change the extension in the file name it doesn’t choose the correct file format even if it is a valid file format. Reading left to right I change the file name first and then choose the file format second.
With release build, it’s similar to the numbers in the PR. I think the vtk<->teem nrrdio<->zlib interface might be suboptimal, because I get much better numbers with pure python.
level 0: 9s (2.1 GB)
level 1 (default): 22s (529 MB)
level 9: 41s (519 MB)