Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Adding invert operator #3065

Closed
wants to merge 6 commits into from

Conversation

datumbox
Copy link
Contributor

@datumbox datumbox commented Nov 30, 2020

Part of #3050

@datumbox datumbox requested a review from fmassa November 30, 2020 21:51
@datumbox datumbox changed the title Adding invert operator [WIP] Adding invert operator Dec 1, 2020
@datumbox datumbox requested a review from vfdev-5 December 2, 2020 18:29
@datumbox datumbox changed the title [WIP] Adding invert operator Adding invert operator Dec 2, 2020
Copy link
Collaborator

@vfdev-5 vfdev-5 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@datumbox thanks for the PR !
I left few comments and I have another remark for autoaugment stuff:
in fixmatch they added a parametrization of invert op with blending: https://github.com/vfdev-5/FixMatch-pytorch/blob/0dc80189be26604734a5c3d563d3be83d4a38d00/ctaugment/ctaugment.py#L98
Should we provide blend as a separate op ? We already do a blending like that for adjust constrast and friends ops...


_assert_channels(img, [1, 3])

max_val = _max_value(img.dtype)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If image dtype is float then max_val will be something very large right ? OK, probably, now I understand the questions asked about float dtype and its range as 0-1.
How about adding an option to the method such that user could specify its own max value. By default can be max dtype...

Copy link
Contributor Author

@datumbox datumbox Dec 3, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yep you are right. I opted for using the same approach as _bend() to determine the bound. I did not optin for passing it as a param to make sure the API is similar as other transformations.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hum, this sounds fishy to me for floating point types. We should probably not be doing 1.79769e+308 - value for doubles, nor 3.40282e+38 - value for floats.

Is there any use-case for applying color transforms to native float images (like satellite or medical data)? If not, we should probably assume that float images are within 0-1 range

Copy link
Collaborator

@vfdev-5 vfdev-5 Dec 4, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For medical imagery I'd use MONAI as reference and it seems like it is possible: https://docs.monai.io/en/latest/transforms.html#intensity . They do not have any assumptions on the range of input data (uint8 or float).

As for satellite imagery, some intensity manipulations in visible spectrum can be also possible.

I think there are 2 ways possible for this op:

  • mention in the docs that this op is working on uint8 only and raise exception for float data in the code
  • add min/max data range as input args and handle any type.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's a great reference, thanks @vfdev-5 !

I think that exposing a min_value / max_value arguments (which defaults to None and has sensible defaults for different data types) is a good trade-off to consider.

We can go in two steps though if we want to be extra cautious, and first raise an exception and then in the future add those extra arguments.

Thoughts?

Returns:
PIL Image or Tensor: Randomly color inverted image.
"""
if self.get_params() < self.p:
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We have decided on getting random apply param with static get_params() ?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've asked @fmassa and he recommended adding it in the get_params().

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The output of get_params should in principle be the parameters we will be using to apply a transformation.
In this case, it would be True / False for applying the transform or not.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@fmassa OK and what to do if there are both to sample: transform random params and random apply one ?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't have a good solution for this one yet. It's a similar story as ColorAdjust, and the solutions are not great.

We might need to revisit our transforms story, maybe breaking it down into two types of transforms.

@datumbox
Copy link
Contributor Author

datumbox commented Dec 3, 2020

Should we provide blend as a separate op ? We already do a blending like that for adjust constrast and friends ops...

I don't currently have a use-case that requires exposing _blend() publicly but I plan to use it for sharpness.

@datumbox
Copy link
Contributor Author

datumbox commented Dec 3, 2020

I'm closing this PR and I'm going to move the development to the autoaugment_transforms branch.

The reason is, there will be 1 PR for each transform and without the ability to stack them I'll either have to wait for each individual PR to be approved and merged before starting the other one or have to deal with a huge number of conflicts as I'm touching the same files.

Please do provide your feedback here though as this transform will serve as the prototype for the rest. Thanks!

@datumbox datumbox closed this Dec 3, 2020
@datumbox datumbox deleted the feature/invert_transorm branch December 14, 2020 17:49
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants