Some transforms (e.g., `Crop`, `Pad`, `CropOrPad`) not compatible with custom Image subclasses with different constructors

[tcollins-hub]

Is there an existing issue for this?

• I have searched the existing issues

Problem summary

Describe the problem
TorchIO spatial transforms (e.g., Crop, Pad, CropOrPad) reconstruct images internally using type(image)(tensor=..., affine=..., type=..., path=...).
If a user-defined subclass of torchio.Image has a different __init__ signature (e.g., requires extra arguments like history), these transforms raise errors and fail.

This issue affects all transforms that reconstruct images, not just Crop.
It prevents users from extending TorchIO Image to store metadata or other extra attributes inside images.

Proposed solution
Introduce an optional hook or method (new_like) that allows subclasses to return a new instance when transforms need to copy/crop/resize the image. Transforms would call this hook if it exists, otherwise fall back to the standard constructor.

Code for reproduction

python
import torchio as tio
import torch

class HistoryScalarImage(tio.ScalarImage):
    def __init__(self, tensor, affine, history, **kwargs):
        super().__init__(tensor=tensor, affine=affine, **kwargs)
        self.history = history

img = HistoryScalarImage(torch.rand(1,10,10,10), affine=torch.eye(4), history=[])
subject = tio.Subject(image=img)
transform = tio.Crop(cropping=2)

Actual outcome

transform(subject) # raises TypeError

Error messages

TypeError

Expected outcome

Transforms should either:

1. Support arbitrary Image subclasses by providing a clone / factory hook (new_like() or similar), or
2. Clearly document that only vanilla TorchIO Image subclasses are supported.

System info

Platform:   Linux-6.8.0-85-generic-x86_64-with-glibc2.39
TorchIO:    0.21.0
PyTorch:    2.1.2
SimpleITK:  2.5.2 (ITK 5.4)
NumPy:      1.26.4
Python:     3.10.13 | packaged by conda-forge | (main, Dec 23 2023, 15:36:39) [GCC 12.3.0]

[siddharth10ss]

Hi! I'd like to work on fixing this issue.

Proposed Solution

I'll implement the new_like() factory method approach you suggested:

1. Add new_like() method to the base Image class
2. Update Crop and ToReferenceSpace transforms to use it
3. Add comprehensive tests

Example:
class HistoryScalarImage(tio.ScalarImage):
def init(self, tensor, affine, history, **kwargs):
super().init(tensor=tensor, affine=affine, **kwargs)
self.history = history
def new_like(self, tensor, affine=None):
return type(self)(
tensor=tensor,
affine=affine or self.affine,
history=self.history,
check_nans=self.check_nans,
reader=self.reader,
)
Can I proceed with this implementation?

[StijnvWijn]

Hello,

I think I am the culprit for this issue, due to my issues with the Cropping transform as described here and here. I see now that I implemented the copying of the Subject in these transforms differently than the Image.

Please notice that the type(self)(**kwargs) only works if you add keyword arguments to the __init__(), but not if you remove them, which resulted in the complex (and kind of ugly) code for the subject copying here

[siddharth10ss]

Thanks for highlighting the kwargs complexity! My implementation addresses this by:

new_like() pattern - Subclasses explicitly define what they need

Fallback mechanism - Uses copy.deepcopy() when new_like() not overridden

No generic kwargs - Avoids the complexity you encountered

This provides both flexibility AND simplicity.

[clawdney]

Hi! I'm interested in helping with this. Could you share more context about the use case?