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

[BUG] Hue color jitter on an all gray or all white image returns a black image #490

Closed
benlansdell opened this issue Jan 27, 2023 · 1 comment
Labels
bug Something isn't working

Comments

@benlansdell
Copy link
Contributor

benlansdell commented Jan 27, 2023

Describe the bug

Hue jitter, via cucim.core.operations.color.color_jitter, on images with a lot (or all) gray seems to overflow and give either black pixels, or an all-black image.

I noticed this when using augmenting images of planes in, e.g., CIFAR: color_jitter with a non-zero hue parameter would render some sky pixels black. I found this issue only comes up when the hue parameter is non-zero -- other jitter parameters didn't seem to affect the behavior. Further experimenting showed that inputting an image of all white or all one shade of gray resulted in color_jitter outputting an image of all zeros.

More specifically:

import cupy as cp
import cucim.core.operations.color as ccl

x_cupy = cp.ones((3, 64, 64)).astype(cp.uint8)*255
x_jitter = ccl.color_jitter(x_cupy,0,0,0,0.1)

#Outputs all zeros, i.e.
(x_jitter == 0).all() # is True

The same behavior occurs for any gray image, e.g. if I make x_cupy a tensor of all intensity 128.

Perhaps this is some rounding/overflow issue since color_jitter seems to convert all inputs to uint8?

Expected behavior

I would expect the output to not be all black but, if the image is all gray then hue jitter should have no effect -- it should output the same gray image. The torch implementation, for instance, behaves how I would expect:

import torch
import numpy as np 
import torchvision
x_np = np.ones((3, 64, 64)).astype(np.uint8)*255
x_torch = torch.tensor(x_np)
x_torch_jitter = torchvision.transforms.ColorJitter(0, 0, 0, 0.1)(x_torch)

#Jittered output is same as input image
(x_torch_jitter == 255).all() # is True

Environment

Running Ubuntu 20.04. cudatoolkit 11.6.2.

Installed cuCIM with pip.
python==3.8.13
cupy==11.2.0
cucim==22.10.00

(torch version for the above example == 1.13.0)

Other notes

  • I came across this issue when using MONAI's RandCuCIM transform for data augmentation, as it calls cucim's color_jitter.
  • I've tried a number of hue parameters -- anything non-zero seems to create the issue. Though the docstring seems to suggest anything between [-0.5, 0.5] is accepted, including negative values, negative values in fact return ValueError: If hue is a single number, it must be non negative. But I suppose that's a separate issue.
@benlansdell benlansdell added the bug Something isn't working label Jan 27, 2023
@benlansdell
Copy link
Contributor Author

benlansdell commented Jan 29, 2023

Looking at the CUDA kernel, here, it seems like the issue lies on line 208, here.

If s == 0 it sets the whole output to zero. But I think HSV is only black if v == 0.

Line 208 should be changed to:

    if (v == 0) {

??

benlansdell added a commit to benlansdell/cucim that referenced this issue Jan 30, 2023
@rapids-bot rapids-bot bot closed this as completed in 77581d1 Feb 1, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

1 participant