Crop volume / resample scalar slowness for large image

Support
1

I sometimes use CropVolume to supersample some of my volumes. For large volumes (e.g., expected size after supersampling is ~20GB), resamplescalarvolume runs multithreadedly (utilizing all cores) and then there is a really long single threaded piece, sometimes taking tens of minutes for the task the finish.

I know the computer is not resource bound (no lack of RAM or anything)? Is it the copying of the contents to the array to the new volume? Would it be sped up somehow?

2

I haven’t looked at code in a long time, I would guess this is due to the CLI communicating the volumes with compression enabled. If someone has time to dig in, it’s probably just a simple change in a flag.

3

You mean during resampling there is data written to disk (and compressed)?

4

Yes, under the hood the CropVolume module uses the Resample Scalar/Vector/DWI CLI module and communicates via files. The CLI management code may need to be tweaked to offer an uncompressed mode.

5

Yes, it would be good to disable the compression. @lassoan

6

The Slicer CLI code already disables compression when writing out volumes but then reads back whatever the CLI writes.

We could probably just remove this line:

Removing it would avoid the deflate/inflate cycle when reading back the data. I don’t see any downsides to this except that it would use a little more disks space temporarily.

1 Like
7

I agree that it does not make sense to enable compression by default for CLI outputs, as they are primarily used for processing. We should from all CLIs this explicit forcing of compression, except modules that may be used for creating data for archiving, such as CreateDICOMSeries. Interestingly, CreateDICOMSeries module already has a useCompression parameter that can be used for enabling compression. I’ll submit a pull request.

1 Like
8

The pull request that disables compression for all output images in all CLI modules by default is available here: