Add dtype to ToCupy

[bhashemian]

Description

This PR allow ToCupy transform define the expected output dtype.

Status

Ready

Types of changes

• Non-breaking change (fix or new feature that would not break existing functionality).
• New tests added to cover the changes.
• Integration tests passed locally by running ./runtests.sh -f -u --net --coverage.
• Quick tests passed locally by running ./runtests.sh --quick --unittests.
• In-line docstrings updated.

[Nic-Ma]

Hi @drbeh ,

Thanks for your enhancement.
May I know your use case for this ToCupy transform? I think cuCIM already outputs data in cupy array?

Thanks.

[bhashemian]

Hi @drbeh ,

Thanks for your enhancement.
May I know your use case for this ToCupy transform? I think cuCIM already outputs data in cupy array?

Thanks.

Hi @Nic-Ma, you're right! cuCIM output data in the cupy array but it also expect the input data to be in cupy.ndarray and in specific data type (if needed). We already have conversion to cupy.ndarray (ToCupy) and this PR add the ability to define dtype for that array.

[Nic-Ma]

Hi @drbeh ,

I see, could you please help provide the program of cuCIM loading part? I am a little bit confused by it also expects the input data to be in cupy.ndarray, I thought cuCIM reads data from file names.

Thanks.

[bhashemian]

Hi @drbeh ,

I see, could you please help provide the program of cuCIM loading part? I am a little bit confused by it also expects the input data to be in cupy.ndarray, I thought cuCIM reads data from file names.

Thanks.

That's a good point. I see where the confusion come from. cuCIM team has developed several transforms that we are going to use them in MONAI in conjunction with other transforms (for instance the torch.Tensor based transforms) via a CuCIM wrapper (#2932). Thus, although cucim has data loading capabilities, a user can use transforms independently.

[Nic-Ma]

OK, I see, thanks for your explanation.
Maybe you can use CastToType transform before ToCupy transform to achieve expected dtype?
I think it's better to make the ToCupy API align with ToTensor and ToNumpy, etc.
@wyli @rijobro What do you guys think?

Thanks in advance.

[bhashemian]

OK, I see, thanks for your explanation.
Maybe you can use CastToType transform before ToCupy transform to achieve expected dtype?
I think it's better to make the ToCupy API align with ToTensor and ToNumpy, etc.
@wyli @rijobro What do you guys think?

Thanks in advance.

Thank you @Nic-Ma for your suggestion. What you are saying would work but will create a redundant copy of the image.
For instance if we have a numpy.ndarray of np.uint8 and use ToCupy, it creates a cupy.ndarray with dtype np.uint8. Then if we call CastToType(np.float32), it will create another cupy.ndarray with dtype np.float32.

This is not efficient specially for large images.I believe we should change the ToTensor and ToNumpy to include dtype too.

[bhashemian]

@Nic-Ma @wyli , I'd really appreciate your help in reviewing the cucim related PRs since we are depending on them for cucim integration and digital pathology performance optimization, which is supposed to be done by the end of the week,

[Nic-Ma]

Hi @drbeh ,

OK, I see your point, as I said in #2926 (comment), to avoid to add more and more args, I will submit a PR to support kwargs directly soon.

Thanks.

[Nic-Ma]

Submitted ticket to track it: #2951
Thanks for raising this topic.

[bhashemian]

Submitted ticket to track it: #2951
Thanks for raising this topic.

@Nic-Ma specifically for ToCupy it only supports dtype and does not support device, so don't you think that can we have this one without kwargs and only with dtype?

[bhashemian]

Hi @Nic-Ma, thank you very much for your constructive comment. I have applied all of them. Please let me know if there is anything else. thanks