This is more of a comment than a bug.
I just want to expanded a volume to accommodate a larger volume during registration. I know I can use padImage in Simple Filters, but I wanted to do it interactively with Crop Volume (as the changes are not uniform). It worked, but only if I chose the 'interpolated cropping", which made the intensity values of the output volume different than original volume, and also more fuzzy.
Adding empty regions around a volume should not affect the registration (and there is a chance that it makes the registration worse).
It was slightly easier to implement voxel-based cropping so that it does not make volume extents larger, but I agree that it would be more consistent to allow growing of the volume in both interpolated and non-interpolated mode. I’ll update the module.
Crop volume module can grow the volume extent in both interpolated and non-interpolated modes in Slicer Preview Release (from rev28544).
Thanks Andras!!!
Hi Andras,
I gave a quick try and there seems two issues:
When performing interpolated cropping, axis directions are determined by ROI’s axis directions. Order of input volume axes has no effect (as they may not even aligned with any of the ROI’s axes).
It works well for me. Please try again. You can set a fill value of 100 to make the padded region more visible.
OK. I see voxel-based cropping is indeed working. What threw me off was the fields didn’t get updated in the volume information tab. I didn’t cross-checked in the volumes module.
However, the behavior for interpolated cropping seems a little awkward, I don’t recall being it like that.
This is the original volume properties:
This is what I see after enlarging the ROI
Scan order is property is changed, and when I look at the volume outside of Slicer, I see a different plane being shown in slices.
Interpolated cropping behavior changed a few years ago, when support for cropping with arbitrarily transformed ROIs was added. The original volume may be non-linearly warped and arbitrarily rotated, so in general there is no clear correspondence between the original and the cropped volume axes, while there is clear correspondence between the cropping ROI and the cropping volume axes. By implementing some heuristics that would try to find the closest match between the original and resampled cropped volume, we would introduce an ambiguity. Implementing this would take some effort and adding one more option would further complicate the GUI.
Good catch, I’ve fixed this now.
Thank you for the clarification and adding padding option.