adjust_hue now supports inputs of type Tensor #2566

CristianManta · 2020-08-09T18:36:45Z

Attempts to solve the bug reported in issue #2563.

Blocked by #2586

vfdev-5 · 2020-08-09T21:35:27Z

@CristianManta thanks for the PR, the main point of unifying inputs of F.adjust_* methods is to ensure that the result is very close to PIL's one. See for example here for adjust_saturation, adjust_brightness etc. I also started working on this feature but not yet sent a PR, if you would like to make your PR landed I can guide you what should be done exactly to have it merged: code, tests, docs.

CristianManta · 2020-08-10T02:10:19Z

@vfdev-5 I would be happy to help on this feature to the best of my ability. I can give it a crack.

vfdev-5 · 2020-08-10T08:20:37Z

@CristianManta sounds great ! Could you please confirm if you could get it done by this week ?
If so, the next step is to update the test: https://github.com/pytorch/vision/blob/master/test/test_functional_tensor.py#L129
There are two problems if we do it straight forward without any adaptations:

vision/test/test_functional_tensor.py

Line 148 in a75fdd4

factor = 3 * torch.rand(1)

range of factor is larger than expected by F.adjust_hue. However, the tests still fail below :

vision/test/test_functional_tensor.py

Line 166 in a75fdd4

self.assertLess(max_diff, 5 / 255 + 1e-5)
We have to verify PIL and Tensor outputs on a small image and adapt assertions accordingly...

EDIT: Forgot to say that we also have to ensure that everything is torch.jit.script-able

CristianManta · 2020-08-10T13:55:39Z

@vfdev-5 I can spend around 2 hours per day on it (including reading about torch.jit.script and other needed stuff) since I have a full-time summer job. I'm also using Python since only 7 months and have a lot to learn/read, so I would say that I would try it tonight and if I'm too lost or feel that I won't be able to complete it by the end of this week, I'll let you know (tonight, Montreal time) so that you can delegate this task to someone else.

So, if I understand correctly, I have to add a few tests in test_adjustments to make sure that the difference between F.adjust_hue and F_t.adjust_hue and the script version is not too big (in a similar fashion to the code you quoted, but with a different factor)? Basically I'll add (F.adjust_hue, F_t.adjust_hue, script_adjust_hue) at line 134 and see how to make the test pass, right?

I'll read about torch.jit.script also, since I never used it before.

vfdev-5 · 2020-08-10T14:04:47Z

@vfdev-5 I can spend around 2 hours per day on it (including reading about torch.jit.script and other needed stuff) since I have a full-time summer job. I'm also using Python since only 7 months and have a lot to learn/read, so I would say that I would try it tonight and if I'm too lost or feel that I won't be able to complete it by the end of this week, I'll let you know (tonight, Montreal time) so that you can delegate this task to someone else.

@CristianManta no worries, you can start it and I can finish your PR by pushing to your branch.

So, if I understand correctly, I have to add a few tests in test_adjustments to make sure that the difference between F.adjust_hue and F_t.adjust_hue and the script version is not too big (in a similar fashion to the code you quoted, but with a different factor)? Basically I'll add (F.adjust_hue, F_t.adjust_hue, script_adjust_hue) at line 134 and see how to make the test pass, right?

yes, and I know that it wont pass as I checked that locally. That's why

We have to verify PIL and Tensor outputs on a small image and adapt assertions accordingly...

(see my above message).

I'll read about torch.jit.script also, since I never used it before.

There is nothing complicated here, mostly the task is to fixed runtime errors while scripting the function and its subfunctions as probably several variables do not have explicitly declare their types.

….jit.script versions.

….py in hopes to make F_t.adjust_hue scriptable...but to no avail.

CristianManta · 2020-08-11T02:27:16Z

@vfdev-5 I added the appropriate assertions in the tests, but of course there is an error when defining torch.jit.script(F_t.adjust_hue) since I guess I need to modify F_t.adjust_hue to make it scriptable. However, I read the tutorials and examples about converting functions to scripts and I can reproduce them on trivial examples like

import torch                                                                                                                                                                                  
@torch.jit.script                                                               
def func(x):                                                                    
    return x**2                                                                 
                                                                                
def func2(z):                                                                   
    return 2*func(2*z)                                                          
print(func.code)                                                                
                                                                                
sc2 = torch.jit.script(func2)                                                   
print(sc2.code)

so I'm not sure to understand why it doesn't work with F_t.adjust_hue. I tried adding type declarations (that you can see in my updated PR) since you mentioned the lack of type declarations. Am I supposed to add a type in front of each variable involved in the function to make it work (I doubt that, because the errors were at the same place regardless of if I added those types or not)?

vfdev-5 · 2020-08-12T10:02:20Z

@CristianManta sorry for delay, yes, you need to do exactly as it is done for example for F_t.adjust_gamma.
Another thing to do is to add type hints to _hsv2rgb and _rgb2hsv functions. In my tests we also have to modify the implementation of _rgb2hsv:

-    s = cr / torch.where(eqc, maxc.new_ones(()), maxc)
+    ones = torch.ones_like(maxc)
+    s = cr / torch.where(eqc, ones, maxc)

-    cr_divisor = torch.where(eqc, maxc.new_ones(()), cr)
+    cr_divisor = torch.where(eqc, ones, cr)

Feel free to ask if you have other questions.

vfdev-5 · 2020-08-12T10:04:15Z

torchvision/transforms/functional_tensor.py

@@ -164,7 +163,7 @@ def adjust_hue(img, hue_factor):
    if img.dtype == torch.uint8:
        img = img.to(dtype=torch.float32) / 255.0

-    img = _rgb2hsv(img)
+    img: Tensor = _rgb2hsv(img)


I think this is not necessary to add : Tensor

vfdev-5 · 2020-08-12T10:04:20Z

torchvision/transforms/functional_tensor.py

@@ -362,7 +361,7 @@ def _rgb2hsv(img):

    cr = maxc - minc
    # Since `eqc => cr = 0`, replacing denominator with 1 when `eqc` is fine.
-    s = cr / torch.where(eqc, maxc.new_ones(()), maxc)
+    s: Tensor = cr / torch.where(eqc, maxc.new_ones(()), maxc)


CristianManta · 2020-08-12T13:40:56Z

Ahh I see, yes I recall that the test generated an error coming from _rgb2hsv and I was running around in circles to try to solve it. I'll continue working on it this evening and I'll add the remaining type hints in the functions headers that are being called. I think I'll also add a raise TypeError when the input does not match the type hint of the function arguments.

…on according to PR's review.

…reased the assertLess bound to make sure that no other test fails.

…al_pil.py as well.

CristianManta · 2020-08-13T02:32:14Z

torchvision/transforms/functional.py

@@ -714,7 +714,7 @@ def adjust_saturation(img: Tensor, saturation_factor: float) -> Tensor:
    return F_t.adjust_saturation(img, saturation_factor)


-def adjust_hue(img: Tensor, hue_factor: float) -> Tensor:


Technically speaking, the type of hue_factor is torch.Tensor of dtype=whatever_torch.rand()'s_output_type_is, but I guess it would be misleading to put hue_factor: Tensor in the header

Also, since we're in functional.py, the type of img would be something like Union[Tensor, PIL], but I cannot use PIL as a type so I left img as it is. Not sure what to do. I don't think putting Any is correct either.

Here the type hints are mostly for torch.jit.script which does not accept type mixing with Union. Let's keep annotations as it is done for other. This is correctdef adjust_hue(img: Tensor, hue_factor: float) -> Tensor:

torchvision/transforms/functional.py

torchvision/transforms/functional_tensor.py

CristianManta · 2020-08-13T03:17:07Z

I think I covered all the type hint problems and I adapted the test to take into account the different range of factor for adjust_hue. The torch.jit.script also seems to work. I also added some comments/remarks to what I just pushed.

I guess the remaining part is to fix the error bound in the assertLess which is now the only source of failure in the tests. I temporarily set it to 5 just to make sure that there are no other issues.

Now, in order to fix it, I'm wondering what approach I should follow. The 5 / 255 factor seems to come from the worst case when there is a conversion from uint8 to torch.float which can be off by at most 1 (floor/ceiling rounding error) before dividing by 255, hence an error of 1 / 255 for one such conversion. But why 5 times? Also, where does the 1e-5 factor come from?

If all of this is correct, then isn't changing the assertion cheating? Shouldn't we rather change F_t.adjust_hue to make it more precise?

vfdev-5

@CristianManta thanks for working on the PR ! I left some comments.

vfdev-5 · 2020-08-13T07:27:34Z

test/test_functional_tensor.py

@@ -146,25 +148,36 @@ def test_adjustments(self):
                img = torch.randint(0, 256, shape, dtype=torch.uint8)

            factor = 3 * torch.rand(1)


As factor should be a float for all ops, let's just apply .item() on it.

vfdev-5 · 2020-08-13T07:31:48Z

test/test_functional_tensor.py

-                img_pil = transforms.ToPILImage()(img)
-                f_img_pil = f(img_pil, factor)
-                f_img = transforms.ToTensor()(f_img_pil)
+            for i, (f, ft, sft) in enumerate(fns):


Maybe it would be more simple to check the type of f like f == F.adjust_hue and redefine factor as factor = torch.rand(1).item() - 0.5 instead of doing if-else with almost the same code for both cases...

vfdev-5 · 2020-08-13T07:34:55Z

torchvision/transforms/functional.py

@@ -714,7 +714,7 @@ def adjust_saturation(img: Tensor, saturation_factor: float) -> Tensor:
    return F_t.adjust_saturation(img, saturation_factor)


-def adjust_hue(img: Tensor, hue_factor: float) -> Tensor:


Here the type hints are mostly for torch.jit.script which does not accept type mixing with Union. Let's keep annotations as it is done for other. This is correctdef adjust_hue(img: Tensor, hue_factor: float) -> Tensor:

torchvision/transforms/functional.py

vfdev-5 · 2020-08-13T07:37:27Z

torchvision/transforms/functional_pil.py

@@ -118,7 +118,7 @@ def adjust_saturation(img, saturation_factor):


 @torch.jit.unused
-def adjust_hue(img, hue_factor):
+def adjust_hue(img, hue_factor: float):


This is not necessary. Otherwise, you can set it as def adjust_hue(img: Any, hue_factor: float):

torchvision/transforms/functional_tensor.py

vfdev-5 · 2020-08-13T07:44:38Z

torchvision/transforms/functional_tensor.py

@@ -344,7 +344,9 @@ def _blend(img1: Tensor, img2: Tensor, ratio: float) -> Tensor:
    return (ratio * img1 + (1 - ratio) * img2).clamp(0, bound).to(img1.dtype)


-def _rgb2hsv(img):
+def _rgb2hsv(img: Tensor) -> Tensor:
+    if not isinstance(img, torch.Tensor):


_rgb2hsv is a private method, I think we can skip type checking and raising error here.
Btw, functional_tensor.py module is intended to be private too, user should not use those functions in the code. Warnings will be added soon according to #2547

vfdev-5 · 2020-08-13T07:45:00Z

torchvision/transforms/functional_tensor.py

@@ -380,7 +383,9 @@ def _rgb2hsv(img):
    return torch.stack((h, s, maxc))


-def _hsv2rgb(img):
+def _hsv2rgb(img: Tensor) -> Tensor:
+    if not isinstance(img, torch.Tensor):


vfdev-5 · 2020-08-13T07:46:40Z

test/test_functional_tensor.py


                # F uses uint8 and F_t uses float, so there is a small
                # difference in values caused by (at most 5) truncations.
                max_diff = (ft_img - f_img).abs().max()
                max_diff_scripted = (sft_img - f_img).abs().max()
-                self.assertLess(max_diff, 5 / 255 + 1e-5)
-                self.assertLess(max_diff_scripted, 5 / 255 + 1e-5)
+                self.assertLess(max_diff, 5 + 1e-5)  # TODO: 5 / 255, not 5


Maybe, we can compare number of different pixels like it is done here:

vision/test/test_functional_tensor.py

Line 587 in 270e02e

num_diff_pixels = (out_tensor != out_pil_tensor).sum().item() / 3.0

vfdev-5 · 2020-08-13T07:56:48Z

Now, in order to fix it, I'm wondering what approach I should follow. The 5 / 255 factor seems to come from the worst case when there is a conversion from uint8 to torch.float which can be off by at most 1 (floor/ceiling rounding error) before dividing by 255, hence an error of 1 / 255 for one such conversion. But why 5 times? Also, where does the 1e-5 factor come from?
If all of this is correct, then isn't changing the assertion cheating? Shouldn't we rather change F_t.adjust_hue to make it more precise?

I was thinking, firstly, to see how different two outputs (PIL and Tensor) are, do we have majority of exact values and few different values or they are all different ? If you could compute F.adjust_hue on a small image and tensor of size 5x5 (e.g. torch.arange(3 * 5 * 5).reshape(3, 5, 5) and post here few values, it would be nice.

Next, we can take a look at F_t.adjust_hue implementation and see if it could be slightly changed to match PIL result.

Finally, we adapt the test such that either we compute the number of different pixels and raise an error if above some threshold. Either, rework current checking of max diff and leave comment what we check.

What do you think ?

CristianManta · 2020-08-13T14:18:10Z

That's a good idea, I'll compute the distances between pairs of images in the 2 norms you mentioned and this should give us a clue more about what's wrong. My suspicions is that many pixels will be different, slightly exceeding the established max difference each.

I'll compute F.adjust_hue on a PIL image, convert to Tensor and re-compute F.adjust_hue on a Tensor (representing the same image) and measure the distances between the 2 outputs. I'll repeat that a few times.

… with hue.

CristianManta · 2020-08-14T03:19:49Z

I fixed the mistakes that you mentioned in the previous review. I also wrote a script to get some statistics about the error differences. If you want to run it, you need to place it one level above the vision directory:

import torch
import vision.torchvision.transforms.functional as F
import vision.torchvision.transforms.transforms as transforms
import vision.torchvision.transforms.functional_tensor as F_t


# Parameters
tol = 1e-5
k = 20

def get_number_of_diff_pixels(img1, img2):
    W = img1.shape[1]
    H = img1.shape[2]
    counter = 0
    for i in range(W):
        for j in range(H):
            for ch in range(3):
                if abs(img1[ch][i][j].item() - img2[ch][i][j].item()) > tol:
                    counter += 1
                    print('The discrepancy was in channel: {} for pixel ({}, {})'.format(ch, i, j))
                    break
    return counter


tensor_img = torch.arange(3 * 5 * 5).reshape(3, 5, 5).to(torch.float) / 255
pil_img = transforms.ToPILImage()(tensor_img)

# first testing if composing the ToPILImage and its inverse produces the 
# original image indeed

test_inverse_pil_img = transforms.ToTensor()(pil_img)
if (test_inverse_pil_img != tensor_img).sum().item() / 3.0 == 0:
    print('ToPILImage composed with its inverse doesn\'t lose accuracy.\n')
else:
    print('ToPILImage composed with its inverse loses accuracy.\n')


for i in range(k + 1):
    hue_factor = -0.5 + i / k
    out_tensor = F.adjust_hue(tensor_img, hue_factor)
    out_pil = F.adjust_hue(pil_img, hue_factor)
    out_pil_to_tensor = transforms.ToTensor()(out_pil)

    # num_diff_pixels = (out_pil_to_tensor != out_tensor).sum().item() / 3.0
    num_diff_pixels = get_number_of_diff_pixels(out_pil_to_tensor, out_tensor)
    print('hue_factor = {}: number of different pixels = {}'.format(hue_factor, num_diff_pixels))
    pct = 100.0 * num_diff_pixels / (tensor_img.shape[1] * tensor_img.shape[2])
    print('percentage of pixels that are different: {}%\n'.format(pct))
    print('------------------------------------------------\n')

# testing if _rgb2hsv and _hsv2rgb are precise:
hsv = F_t._rgb2hsv(tensor_img)
rgb = F_t._hsv2rgb(hsv)

diff = get_number_of_diff_pixels(rgb, tensor_img)
print('diff = {}'.format(diff))

On some relatively mild tolerance tol, on most hue_factor values tried, all 25 pixels differed by more than tol when comparing the original tensor to the one got using the PIL transformations. For instance, if you set tol = 1e-5 (even 1e-4), it looks pretty bad. In particular, when i = 10, hue_factor = 0 and the image is supposed to be left unchanged. Yet, all 25 pixels differ. The problem doesn't seem to favour one channel in particular.

I also tested to see if the 2 conversions _rgb2hsv and its inverse have bad accuracy by composing one by the other and comparing with the original tensor. A difference can already be noticed with tol = 1e-7.

Sorry if the output of the script isn't pretty. I didn't have time to make it prettier

vfdev-5 · 2020-08-14T07:32:26Z

test/test_functional_tensor.py

            scripted_fn = torch.jit.script(f)
            scripted_fn(img)

-            f = transforms.ColorJitter(saturation=factor.item())
+            f = transforms.ColorJitter(hue=abs(hue_factor))


Why do you use abs here ?

Because the ColorJitter class only takes hue inputs that are non negative:

vision/torchvision/transforms/transforms.py

Line 1024 in c547e5c

if value < 0:

I also had to create 2 new variables, bcs_factor and hue_factor because after the inner loop, once factor has been overwritten, I still needed the original factor and hue_factor

vfdev-5 · 2020-08-14T22:33:29Z

@CristianManta I was working on the test of another color transform: rgb_to_grayscale and as some of adjust_* uses it I think it would be better to refactor this test_adjustments into separate tests and follow the same test schema as for test_adjust_gamma. Here is my working branch: d016cab on that.
I think it would be better to rewrite the test of adjust_hue in the same way.

…h by simple copy/paste and added the test_adjust_hue and ColorJitter class interface test in the same style (class interface test was removed in vfdev-5's branch for some reason).

CristianManta · 2020-08-15T14:40:24Z

Ok, so can I also remove test_adjustments from there since we already do those tests in test_functional_tensor.py?

vfdev-5 · 2020-08-15T14:44:24Z

Yes, you can remove test_adjustments from test_transforms_tensor.py, but we need to add a test for ColorJitter with all 4 options: brightness, contrast, saturation and hue.

… ColorJitter class interface test in test_transforms_tensor.py.

CristianManta · 2020-08-19T02:41:11Z

@vfdev-5 There is still one more test failing, test_adjust_hue reports that the difference between pil and tensor is too big still. I tried fixing this by using colorsys instead of _rgb2hsv and _hsv2rgb to perhaps reduce error coming from them, but colorsys functions are not scriptable. What should I do?

fmassa · 2020-08-20T13:24:20Z

@CristianManta I think there might be some changes that went in this PR that are unrelated (in the tests).

About the differences from _rgb2hsv and _hsv2rgb, do they also fail on master? I think I've seen some occasional failures.
In the end, our implementation should follow more closely the official definitions. PIL does some approximations for working with uint8 images, so I'm not so worried if it fails for some input types.

CristianManta · 2020-08-21T13:34:16Z

@fmassa I realize that since this PR was opened 12 days ago, many changes were merged into master since then, so it's worth re-trying with the new changes. Also, about the unrelated changes that went into this PR, I think it's because I copied some stuff from d016cab on which @vfdev-5 was working since his changes were related somewhat.

Tonight I'll save my 4 changed files elsewhere, copy the new versions of them from master into my branch, and manually re-change only the parts that are relevant to adjust_hue, this should hopefully resolve conflicts as well. I'll re-run the tests afterwards

CristianManta · 2020-08-21T23:26:02Z

@fmassa I just updated the PR and solved the conflict. I kept the d016cab style for testing the adjustments, and incorporated the cuda case. And of course, _test_adjust_hue (the goal of this PR) is still there.

I saw that, in fact, only cuda test coverage has been merged in master in torchvision/transforms/functional_tensor since the last time and so the adjust_hue is still the same. There's still the same (only) failure from test_functional_tensor:

FAIL: test_adjustments (test_functional_tensor.Tester)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/.../vision/test/test_functional_tensor.py", line 232, in test_adjustments
    self._test_adjust_hue("cpu")
  File "/.../vision/test/test_functional_tensor.py", line 225, in _test_adjust_hue
    device=device
  File "/.../vision/test/test_functional_tensor.py", line 187, in _test_adjust_fn
    msg="{}: tensor:\n{} \ndid not equal PIL tensor:\n{}".format(msg, rbg_tensor, adjusted_pil_tensor)
AssertionError: 9.0 not less than or equal to 1.0 : None, {'hue_factor': -0.5}: tensor:
tensor([[[236.,   3., 122.,  ..., 178., 126., 146.],
         [222.,  94.,  52.,  ..., 229., 112.,  17.],
         [ 79., 143., 161.,  ...,  69., 204.,  19.],
         ...,
         [ 73., 131., 223.,  ..., 239.,  17., 140.],
         [ 79., 115.,  59.,  ..., 223.,  73., 205.],
         [169.,  15., 213.,  ..., 169., 186.,  42.]],

        [[162., 132., 172.,  ..., 149., 245., 202.],
         [ 44.,  97.,  12.,  ...,  62.,  80.,  70.],
         [ 67.,  11., 185.,  ..., 217., 202., 134.],
         ...,
         [107.,  42., 226.,  ...,  66.,  26., 123.],
         [117., 247., 239.,  ..., 172., 134.,  79.],
         [155., 142., 183.,  ...,   4., 185., 184.]],

        [[ 12., 219., 114.,  ..., 202.,  91.,  55.],
         [145., 183., 143.,  ..., 225.,  60.,  72.],
         [ 40., 245., 249.,  ...,  42.,  92.,  13.],
         ...,
         [203., 220.,  64.,  ...,  21., 207.,  27.],
         [138.,  22., 202.,  ..., 210., 159., 247.],
         [ 47., 189.,  41.,  ...,  77., 231., 232.]]]) 
did not equal PIL tensor:
tensor([[[236.,   3., 122.,  ..., 179., 127., 145.],
         [222.,  94.,  56.,  ..., 229., 112.,  17.],
         [ 79., 149., 161.,  ...,  68., 204.,  20.],
         ...,
         [ 74., 134., 224.,  ..., 239.,  19., 140.],
         [ 79., 117.,  59.,  ..., 223.,  74., 210.],
         [169.,  16., 213.,  ..., 169., 189.,  44.]],

        [[165., 125., 172.,  ..., 150., 245., 202.],
         [ 44.,  94.,  13.,  ...,  63.,  80.,  69.],
         [ 67.,  12., 184.,  ..., 217., 203., 134.],
         ...,
         [104.,  42., 226.,  ...,  68.,  23., 123.],
         [115., 247., 239.,  ..., 172., 134.,  80.],
         [156., 138., 183.,  ...,   5., 186., 181.]],

        [[ 12., 219., 115.,  ..., 202.,  91.,  56.],
         [141., 183., 143.,  ..., 219.,  60.,  72.],
         [ 41., 245., 249.,  ...,  43.,  92.,  14.],
         ...,
         [203., 220.,  65.,  ...,  22., 207.,  27.],
         [138.,  22., 203.,  ..., 209., 159., 247.],
         [ 47., 189.,  43.,  ...,  74., 231., 232.]]])

----------------------------------------------------------------------

fmassa · 2020-08-31T14:16:46Z

@vfdev-5 could you help take this PR into completion?

… adjust_hue_tensor

- adjust hue - color jitter

…t_hue_tensor

vfdev-5 · 2020-09-02T09:12:52Z

Travis failed: https://travis-ci.org/github/pytorch/vision/jobs/723374281

/functional_tensor.py", line 197, in adjust_hue
E               img = _rgb2hsv(img)
E               h, s, v = img.unbind(0)
E               h += hue_factor
E               ~~~~~~~~~~~~~~~ <--- HERE
E               h = h % 1.0
E               img = torch.stack((h, s, v))
E           RuntimeError: Output 0 of UnbindBackward is a view and is being modified inplace. This view is the output of a function that returns multiple views. Such functions do not allow the output views to be modified inplace. You should replace the inplace operation by an out-of-place one.

EDIT: fixed in c58d151

…t_hue_tensor

…_tensor

- fixes irreproducible failing test on Travis CI

fmassa

One more comment, otherwise looks good to me

torchvision/transforms/functional_tensor.py

fmassa

Thanks a lot @CristianManta and @vfdev-5 !

yaox12 · 2020-09-03T08:04:06Z

Hi, I think the current F_t.adjust_hue cannot process images in batchs, which is inconsistent with F_t.adjust_saturation, F_t.adjust_brightness etc.

vfdev-5 · 2020-09-03T08:06:39Z

@yaox12 yes, current implementation should be improved for that case. Batch support will be covered by #2583

* adjust_hue now supports inputs of type Tensor * Added comparison between original adjust_hue and its Tensor and torch.jit.script versions. * Added a few type checkings related to adjust_hue in functional_tensor.py in hopes to make F_t.adjust_hue scriptable...but to no avail. * Changed implementation of _rgb2hsv and removed useless type declaration according to PR's review. * Handled the range of hue_factor in the assertions and temporarily increased the assertLess bound to make sure that no other test fails. * Fixed some lint issues with CircleCI and added type hints in functional_pil.py as well. * Corrected type hint mistakes. * Followed PR review recommendations and added test for class interface with hue. * Refactored test_functional_tensor.py to match vfdev-5's d016cab branch by simple copy/paste and added the test_adjust_hue and ColorJitter class interface test in the same style (class interface test was removed in vfdev-5's branch for some reason). * Removed test_adjustments from test_transforms_tensor.py and moved the ColorJitter class interface test in test_transforms_tensor.py. * Added cuda test cases for test_adjustments and tried to fix conflict. * Updated tests - adjust hue - color jitter * Fixes incompatible devices * Increased tol for cuda tests * Fixes potential issue with inplace op - fixes irreproducible failing test on Travis CI * Reverted fmod -> % Co-authored-by: vfdev-5 <[email protected]>

adjust_hue now supports inputs of type Tensor

653d2fd

CristianManta mentioned this pull request Aug 9, 2020

BUG: ColorJitter in torchvision.transforms #2563

Closed

CristianManta added 2 commits August 10, 2020 20:36

Added comparison between original adjust_hue and its Tensor and torch…

ff93f78

….jit.script versions.

Added a few type checkings related to adjust_hue in functional_tensor…

b565af5

….py in hopes to make F_t.adjust_hue scriptable...but to no avail.

vfdev-5 reviewed Aug 12, 2020

View reviewed changes

CristianManta added 4 commits August 12, 2020 18:14

Changed implementation of _rgb2hsv and removed useless type declarati…

535d1de

…on according to PR's review.

Handled the range of hue_factor in the assertions and temporarily inc…

5f9ba27

…reased the assertLess bound to make sure that no other test fails.

Fixed some lint issues with CircleCI and added type hints in function…

3f6c5a5

…al_pil.py as well.

Corrected type hint mistakes.

270e02e

CristianManta commented Aug 13, 2020

View reviewed changes

torchvision/transforms/functional.py Show resolved Hide resolved

CristianManta commented Aug 13, 2020

View reviewed changes

torchvision/transforms/functional_tensor.py Show resolved Hide resolved

vfdev-5 reviewed Aug 13, 2020

View reviewed changes

Followed PR review recommendations and added test for class interface…

3b072db

… with hue.

vfdev-5 reviewed Aug 14, 2020

View reviewed changes

Refactored test_functional_tensor.py to match vfdev-5's d016cab branc…

bdae1cc

…h by simple copy/paste and added the test_adjust_hue and ColorJitter class interface test in the same style (class interface test was removed in vfdev-5's branch for some reason).

Removed test_adjustments from test_transforms_tensor.py and moved the…

70cff26

… ColorJitter class interface test in test_transforms_tensor.py.

vfdev-5 mentioned this pull request Aug 18, 2020

[BC-breaking] Unified inputs for grayscale ops and transforms #2586

Merged

CristianManta and others added 2 commits August 21, 2020 19:03

Added cuda test cases for test_adjustments and tried to fix conflict.

bb7ec8c

Merge branch 'master' into adjust_hue_tensor

aead63d

[WIP] Merge branch 'master' of https://github.com/pytorch/vision into…

e28e558

… adjust_hue_tensor

fmassa mentioned this pull request Sep 1, 2020

Unify Tensor and PIL transforms #2292

Closed

16 tasks

vfdev-5 added 4 commits September 1, 2020 23:14

Updated tests

d4dd848

- adjust hue - color jitter

Fixes incompatible devices

8551011

Increased tol for cuda tests

71185bd

Merge branch 'master' of https://github.com/pytorch/vision into adjus…

3f23938

…t_hue_tensor

vfdev-5 added 3 commits September 2, 2020 12:18

Merge branch 'master' of https://github.com/pytorch/vision into adjus…

38f33e7

…t_hue_tensor

Merge branch 'master' of github.com:pytorch/vision into cm/adjust_hue…

e8b5f28

…_tensor

Fixes potential issue with inplace op

c58d151

- fixes irreproducible failing test on Travis CI

vfdev-5 requested a review from fmassa September 2, 2020 12:30

fmassa reviewed Sep 2, 2020

View reviewed changes

torchvision/transforms/functional_tensor.py Outdated Show resolved Hide resolved

Reverted fmod -> %

a143835

vfdev-5 reviewed Sep 2, 2020

View reviewed changes

torchvision/transforms/functional_tensor.py Show resolved Hide resolved

fmassa approved these changes Sep 3, 2020

View reviewed changes

fmassa merged commit bb88c45 into pytorch:master Sep 3, 2020

		@@ -714,7 +714,7 @@ def adjust_saturation(img: Tensor, saturation_factor: float) -> Tensor:
		return F_t.adjust_saturation(img, saturation_factor)


		def adjust_hue(img: Tensor, hue_factor: float) -> Tensor:

		@@ -146,25 +148,36 @@ def test_adjustments(self):
		img = torch.randint(0, 256, shape, dtype=torch.uint8)

		factor = 3 * torch.rand(1)

adjust_hue now supports inputs of type Tensor #2566

adjust_hue now supports inputs of type Tensor #2566

Conversation

CristianManta commented Aug 9, 2020 • edited by vfdev-5 Loading

vfdev-5 commented Aug 9, 2020 • edited Loading

CristianManta commented Aug 10, 2020 • edited Loading

vfdev-5 commented Aug 10, 2020 • edited Loading

CristianManta commented Aug 10, 2020 • edited Loading

vfdev-5 commented Aug 10, 2020 • edited Loading

CristianManta commented Aug 11, 2020

vfdev-5 commented Aug 12, 2020

Choose a reason for hiding this comment

Choose a reason for hiding this comment

CristianManta commented Aug 12, 2020 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

CristianManta commented Aug 13, 2020 • edited Loading

vfdev-5 left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

vfdev-5 commented Aug 13, 2020 • edited Loading

CristianManta commented Aug 13, 2020

CristianManta commented Aug 14, 2020 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

vfdev-5 commented Aug 14, 2020 • edited Loading

CristianManta commented Aug 15, 2020

vfdev-5 commented Aug 15, 2020

CristianManta commented Aug 19, 2020 • edited Loading

fmassa commented Aug 20, 2020

CristianManta commented Aug 21, 2020

CristianManta commented Aug 21, 2020 • edited Loading

fmassa commented Aug 31, 2020

vfdev-5 commented Sep 2, 2020 • edited Loading

fmassa left a comment

Choose a reason for hiding this comment

fmassa left a comment

Choose a reason for hiding this comment

yaox12 commented Sep 3, 2020 • edited Loading

vfdev-5 commented Sep 3, 2020 • edited Loading

CristianManta commented Aug 9, 2020 •

edited by vfdev-5

Loading

vfdev-5 commented Aug 9, 2020 •

edited

Loading

CristianManta commented Aug 10, 2020 •

edited

Loading

vfdev-5 commented Aug 10, 2020 •

edited

Loading

CristianManta commented Aug 10, 2020 •

edited

Loading

vfdev-5 commented Aug 10, 2020 •

edited

Loading

CristianManta commented Aug 12, 2020 •

edited

Loading

CristianManta commented Aug 13, 2020 •

edited

Loading

vfdev-5 commented Aug 13, 2020 •

edited

Loading

CristianManta commented Aug 14, 2020 •

edited

Loading

vfdev-5 commented Aug 14, 2020 •

edited

Loading

CristianManta commented Aug 19, 2020 •

edited

Loading

CristianManta commented Aug 21, 2020 •

edited

Loading

vfdev-5 commented Sep 2, 2020 •

edited

Loading

yaox12 commented Sep 3, 2020 •

edited

Loading

vfdev-5 commented Sep 3, 2020 •

edited

Loading