# Crop volume / resample scalar slowness for large image

**URL:** <https://discourse.slicer.org/t/crop-volume-resample-scalar-slowness-for-large-image/34985>\
**Category:** Support\
**Created:** [March 19, 2024, 9:14pm UTC](https://discourse.slicer.org/t/crop-volume-resample-scalar-slowness-for-large-image/34985 "2024-03-19T21:14:26Z")\
**Posts on this page:** 8\
**Page:** 1

<div class="post-metadata">

**Author:** ![muratmaga](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/muratmaga/32/3622_2.png) [@muratmaga](https://discourse.slicer.org/u/muratmaga)\
**Post date:** [March 19, 2024, 9:14pm UTC](https://discourse.slicer.org/t/crop-volume-resample-scalar-slowness-for-large-image/34985/1 "2024-03-19T21:14:26Z")

</div>

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?

---

<div class="post-metadata">

**Author:** ![pieper](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/pieper/32/8_2.png) [@pieper](https://discourse.slicer.org/u/pieper)\
**Post date:** [August 4, 2024, 4:38pm UTC](https://discourse.slicer.org/t/crop-volume-resample-scalar-slowness-for-large-image/34985/2 "2024-08-04T16:38:22Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![muratmaga](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/muratmaga/32/3622_2.png) [@muratmaga](https://discourse.slicer.org/u/muratmaga)\
**Post date:** [August 4, 2024, 8:56pm UTC](https://discourse.slicer.org/t/crop-volume-resample-scalar-slowness-for-large-image/34985/3 "2024-08-04T20:56:30Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![pieper](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/pieper/32/8_2.png) [@pieper](https://discourse.slicer.org/u/pieper)\
**Post date:** [August 5, 2024, 6:14pm UTC](https://discourse.slicer.org/t/crop-volume-resample-scalar-slowness-for-large-image/34985/4 "2024-08-05T18:14:39Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![muratmaga](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/muratmaga/32/3622_2.png) [@muratmaga](https://discourse.slicer.org/u/muratmaga)\
**Post date:** [August 5, 2024, 11:27pm UTC](https://discourse.slicer.org/t/crop-volume-resample-scalar-slowness-for-large-image/34985/5 "2024-08-05T23:27:41Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![pieper](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/pieper/32/8_2.png) [@pieper](https://discourse.slicer.org/u/pieper)\
**Post date:** [August 6, 2024, 8:43pm UTC](https://discourse.slicer.org/t/crop-volume-resample-scalar-slowness-for-large-image/34985/6 "2024-08-06T20:43:55Z")

</div>

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:

> <https://github.com/Slicer/Slicer/blob/main/Modules/CLI/ResampleScalarVectorDWIVolume/ResampleScalarVectorDWIVolume.cxx#L1299>

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.

---

<div class="post-metadata">

**Author:** ![lassoan](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/lassoan/32/13_2.png) [@lassoan](https://discourse.slicer.org/u/lassoan)\
**Post date:** [August 12, 2024, 12:30pm UTC](https://discourse.slicer.org/t/crop-volume-resample-scalar-slowness-for-large-image/34985/7 "2024-08-12T12:30:25Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![lassoan](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/lassoan/32/13_2.png) [@lassoan](https://discourse.slicer.org/u/lassoan)\
**Post date:** [August 12, 2024, 11:16pm UTC](https://discourse.slicer.org/t/crop-volume-resample-scalar-slowness-for-large-image/34985/8 "2024-08-12T23:16:38Z")

</div>

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

> <https://github.com/Slicer/Slicer/pull/7885>
>
> CLI modules are primarily used for processing and the output file is just used f…or temporary storage. Therefore, usually compression has no benefits, but it slows down the execution time.
> 
> If it turns out in the future that some modules would benefit from having compressed output, those modules could get an optional "--useCompression" flag, similarly to CreateDICOMSeries module.
> 
> See discussion at https://discourse.slicer.org/t/crop-volume-resample-scalar-slowness-for-large-image/34985/6