modified transforms.py to accept list of PIL images

[quantummole]

if input is a list of images then output is a list of images else old behaviour is retained
if params need to be computed for every img, then they are computed based on the fist img of the list
this was done to apply the same random transform on each img for example - image segmentation

[fmassa]

Hi,

Thanks for the PR!

I'm not sure that this is the way we would want those problems to be handled. It indeed adds a strong assumption that everything in the list if a PIL Image.
This is the case for Image Segmentation, but still breaks some assumptions even in this case.
For example, we don't want to apply bilinear interpolation for the ground-truth segmentation masks, so this should be handled differently and that's not covered in this PR. Same thing for rotations, scalings, etc.

For this reason, I think that we really want to keep the class interface as simple as possible, and let the user leverage the functional interface to perform their fine-grained transformations themselves.

What do you think?

[quantummole]

You do have a point. Then is it possible for us to have a uniform interface like get_params for transforms like random_grayscale etc which would return a random bool that we can use to chain methods inside the dataset.

[fmassa]

Oh, yes, definitely!
RandomGrayscale should have a get_params in there, it was an oversight that it didn't have it.
Ideally, all transforms that have random parameters should have them via a get_params staticmethod.

Could you send a PR fixing this in RandomGrayscale?

[fmassa]

Thanks for updating the PR. I have a few comments

[fmassa]

Actually, now I remember why we didn't have get_params for those functions: it was because they were fairly trivial, and generally simpler to implement in the code itself.
I'm not against adding it here, but I'd like to know how you are planning to write your code to support the semantic segmentation use-case

[quantummole]

I was planning to take a list of transforms as input and then apply them sequentially using compose. I can just pass two lists one for the functional equivalents and one for the actual transforms, now if the actual transforms have a standard interface through which we can get parameters it will make it simpler to abstract away the kind of transforms that we would be applying out of the dataset code

[fmassa]

The problem is that get_params is a staticmethod, so it's not that easy to abstract that away.
In those cases, I think it's just way simpler to write your own transform, using purely the functional interface

class MyTransform(object):
    def __init__(self, **kwargs):
        # store params here

    def __call__(self, img, masks, etc):
        if random.rand() > self.prob1:
               # do my magic
        return img, masks, etc