Added gray image support to adjust_saturation function

[VinhLoiIT]

This resolves #4466

• Update code for adjust_contrast
• Update code for adjust_saturation
• Update document for adjust_contrast
• Update document for adjust_saturation

cc @vfdev-5 @datumbox

[VinhLoiIT]

I found that ColorJitter depends on this issue as well while reviewing the documentation, and currently, the tests just run on 3-channel images.

vision/test/test_transforms_tensor.py

Line 70 in 9252436

tensor, pil_img = _create_data(26, 34, device=device)

[vfdev-5]

@VinhLoiIT I think we can do the same trick with channels there

[vfdev-5]

For example:

@pytest.mark.parametrize('device', cpu_and_gpu())
@pytest.mark.parametrize('channels', [3, 1])
class TestColorJitter:

    @pytest.mark.parametrize('brightness', [0.1, 0.5, 1.0, 1.34, (0.3, 0.7), [0.4, 0.5]])
    def test_color_jitter_brightness(self, brightness, device, channels):
        tol = 1.0 + 1e-10
        meth_kwargs = {"brightness": brightness}
        _test_class_op(
            T.ColorJitter, meth_kwargs=meth_kwargs, test_exact_match=False, device=device,
            tol=tol, agg_method="max", channels=channels
        )
    # same of other tests

cc @NicolasHug is it OK to do that like that with parametrize on TestColorJitter as for device ?

[NicolasHug]

cc @NicolasHug is it OK to do that like that with parametrize on TestColorJitter as for device ?

Sorry I'm missing some context. If you're asking whether we can add a parametrization for channel at the class level, then yes, as long as channel is an argument of all the methods :)

[vfdev-5]

cc @NicolasHug is it OK to do that like that with parametrize on TestColorJitter as for device ?

Sorry I'm missing some context. If you're asking whether we can add a parametrization for channel at the class level, then yes, as long as channel is an argument of all the methods :)

yes, I mean, do we have any restrictions on what we parametrize and where. Device parameter is something very generic and applicable to everyone. Channel as parameter is rather specific to TestColorJitter and maybe other specific testers. Even if we can technically do as suggested in the example, we may have some thought on how to parametrize and where.

[NicolasHug]

do we have any restrictions on what we parametrize and where

Not really, we should just consider parametrizations to be glorified for-loops. If it makes sense to run a test with different values, then parametrization is relevant.

In this specific case of TestColorJitter, since the tests are testing different sub-transforms, I think it makes sense to add the parametrization at the class level.

[vfdev-5]

Thanks for the PR @VinhLoiIT
I left few nit comments, please fix them.

[VinhLoiIT]

I don't know whether to update the documentation as well as channel testing of AutoAug and related classes in #4457 inside this PR or to create another PR for that?

[vfdev-5]

@VinhLoiIT @datumbox what about AutoAugment, does it support gray images now with this PR ? If yes, let's update the doc as well

[VinhLoiIT]

@vfdev-5 I'm writing tests for that now.

Currently, the tests use fill=(128,128,128):

vision/test/test_transforms.py

Lines 1494 to 1503 in 4ef8e6b

	@pytest.mark.parametrize('num_ops', [1, 2, 3])
	@pytest.mark.parametrize('magnitude', [7, 9, 11])
	@pytest.mark.parametrize('fill', [None, 85, (128, 128, 128)])
	def test_randaugment(num_ops, magnitude, fill):
	random.seed(42)
	img = Image.open(GRACE_HOPPER)
	transform = transforms.RandAugment(num_ops=num_ops, magnitude=magnitude, fill=fill)
	for _ in range(100):
	img = transform(img)
	transform.__repr__()

which conflicts with my proposed changes as following:

@pytest.mark.parametrize('num_ops', [1, 2, 3])
@pytest.mark.parametrize('magnitude', [7, 9, 11])
@pytest.mark.parametrize('fill', [None, 85, (128, 128, 128)])
@pytest.mark.parametrize('grayscale', [True, False])
def test_randaugment(num_ops, magnitude, fill, grayscale):
    random.seed(42)
    img = Image.open(GRACE_HOPPER)
    if grayscale:
        img = img.convert('L')
    # conflict when fill=(128,128,128) and grayscale=True
    transform = transforms.RandAugment(num_ops=num_ops, magnitude=magnitude, fill=fill)
    for _ in range(100):
        img = transform(img)
    transform.__repr__()

Do you have any suggestion here?

[vfdev-5]

@VinhLoiIT how about doing the following:

    if grayscale:
        img = img.convert('L')
        fill = (fill[0], ) if isinstance(fill, tuple) else fill

[VinhLoiIT]

@vfdev-5 Okay it works now. I'll update the tests soon.

[datumbox]

@VinhLoiIT FYI, some of the failing tests seems related:

test_adjust_sharpness[1-config3-dtype1-cpu] - test.test_functional_tensor
Traceback (most recent call last):
  File "/root/project/test/test_functional_tensor.py", line 771, in test_adjust_sharpness
    check_functional_vs_PIL_vs_scripted(
  File "/root/project/test/test_functional_tensor.py", line 678, in check_functional_vs_PIL_vs_scripted
    _test_fn_on_batch(batch_tensors, fn, scripted_fn_atol=atol, **config)
  File "/root/project/test/common_utils.py", line 208, in _test_fn_on_batch
    assert_equal(transformed_img, transformed_batch[i, ...])
  File "/root/project/env/lib/python3.8/site-packages/torch/testing/_asserts.py", line 971, in assert_close
    raise error_meta.to_error()
AssertionError: Tensor-likes are not equal!

Mismatched elements: 45 / 288 (15.6%)
Greatest absolute difference: 5.960464477539063e-08 at index (0, 2, 11)
Greatest relative difference: 4.704487610731877e-06 at index (0, 11, 15)

[datumbox]

Thanks for the PR @VinhLoiIT.

The test failures look like a tolerance problem and might be resolved by adjusting it.

[datumbox]

LGTM from my side, I'll leave it to @vfdev-5 for the final approval and merge.

Thanks for the contribution @VinhLoiIT!

[vfdev-5]

Looks good to me as well!
@VinhLoiIT thanks for the PR!