We have completed a number of annotations segmenting abdominal tissue on one vertebral level. We are unable however to reopen the mrml file we have saved, there is an intermittent error appearing suggesting the load has failed. We are cropping the images to ensure our annotation remains within the required level. When we save the annotation we use the uncropped file as the reference volume. however, the size of the annotation is equal to the cropped volume instead of matching the size of the uncropped volume, this should not be the case. I have attached an image of the error code. Is there a cause to this? This issue is mostly intermittent and has affected 50% of our cases. Please offer a solution?
Is your Y: drive a dropbox or google drive like folder? There have been some reported issues saving to those. Try using local drives for saving. If you can replicate an error let us know the exact steps and environment.
our processes have included saving to local devices initially and then transferring to a shared drive mainly because the time taken to save onto the shared drive directly is considerably longer…the issue has occurred saving to local devices and transferring to a shared drive. the series on the shared drive have shown this mismatch. we will try to use a locally saved series for analyses and see if it works
You can also have a look at the application log. It may contain additional details about what exactly failed while attempting to load the image.
This is probably unrelated to the failure to save/read a scene from virtual file systems. If you export the segmentation to a labelmap volume then the geometry of that labelmap will match the specified reference node. However, if you just save the scene, the segment geometry will still be the same (probably the cropped volume, if that was used for segmentation). If you can describe any reproducible workflow that does not work as you expect then let us know and we will look into it.
it is quite strange, when we saved the scene 50% of the segment geometry matched what the cropped image was and 50% matched the un-cropped segment. We crop the images at the start of our annotation to our desired vertebral level. We can not work out why the geometry changes during our processes. Could we have flicked back to the uncropped images to check if the annotation remained within the crop level before we have saved? however, when we save the file we save the scene, mrml, both cropped and uncropped series and the seg.nrrd file. I dont understand.
Additionally, we have loading errors each time we reload the mrml back onto 3d slicer (occasionally they are critical errors) we do not know why this happens [please see attached error picture above]. We dont think it related to the geometry but I can give you a workflow of how we load, annotate and save if you wish to better understand our issue?
I can understand that the behavior may be hard to follow, but it sounds like everything works as it should. What is probably not clear for users is that choosing a master volume has important consequence:
The master volume that is selected the very first time after the segmentation is created is used to determine the segmentation’s labelmap representation geometry (extent, resolution, axis directions, origin).
Note: changing the master volume does not affect the segmentation’s labelmap representation geometry. To make changes to the geometry (make the extent larger, the resolution finer, etc.) click “Specify geometry” button next to the master volume selector, …
The solution is to either change the geometry in your segmentations ;or export labelmaps from the segmentations, using the non-cropped volume as reference volume.
If you share a scene with use that fails to load then we might be able to tell what went wrong when it was saved. A workflow that reproduces the issue would be great (the simplest the workflow the better), but I suspect it is simply file corruption due to problems in the virtual file system.
Virtual file systems provided Box and Google work well for simple bulk data copy but known to cause data corruption if you try to use it as a working directory. The issue with these network-backed virtual file systems is that they cannot handle large amount of random read/write operations on many files in quick succession - at some point they just fail, maybe they even return with an error, but these errors may happen in completely unexpected locations that it is very hard to capture and handle them properly at the application level. These virtual file systems effectively work as a faulty hard disk. It would be very expensive to harden a complex application’s all file reading/writing operations against all possible file system errors, so in practice the conclusion is to not work on these drives directly, but only for bulk copy to/from local drive.
Note that Dropbox and OneDrive does not have such problem, because they store the files on local disk and network synchronization happens in the background.
