Add float support to ColorJitter

[vballoli]

Fixes #2669 and adds relevant typing to the arguments.

[codecov]

Codecov Report

Merging #2672 into master will decrease coverage by 0.06%.
The diff coverage is 33.33%.

@@            Coverage Diff             @@
##           master    #2672      +/-   ##
==========================================
- Coverage   72.41%   72.35%   -0.07%     
==========================================
  Files          95       95              
  Lines        8245     8254       +9     
  Branches     1308     1312       +4     
==========================================
+ Hits         5971     5972       +1     
- Misses       1858     1866       +8     
  Partials      416      416              

Impacted Files	Coverage Δ
torchvision/transforms/transforms.py	75.59% <33.33%> (-0.94%)	⬇️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update a4736ea...2b0c8a0. Read the comment docs.

[fmassa]

Thanks for the PR!

I think there is an issue with the current way you implement this.

Also, could you add tests for using the get_params interface for the case you are trying to fix?

[fmassa]

We are using the returned value of _check_input, so this doesn't actually do anything IMO.

Could we instead just do

brightness = ColorJitter._check_input(brightness, 'brightness')

without the conditional on float?

[vballoli]

Yeah that definitely makes sense, not sure how I missed that.

[vfdev-5]

@fmassa according to what we discussed previously, maybe it would be better to get back ColorJitter.get_params to forward ? In this case, fix with Union wont work with torch jit script, right ?

[fmassa]

@vfdev-5 the Union is not the only issue, but also that get_params returns a Transforms, which IMO doesn't work with torchscript

[vfdev-5]

@fmassa that's true about current Compose implementation but taking into account #2645 it may be possible to reuse ColorJitter.get_params later ?

[fmassa]

@vfdev-5

@fmassa that's true about current Compose implementation but taking into account #2645 it may be possible to reuse ColorJitter.get_params later ?

Maybe in the future we could change that, but I wouldn't focus on it now. But we could have an open issue to track this inconsistency down.