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

Add a guard to avoid NaNs appearing in the conversion from rgb to hsv. #70

Merged
merged 1 commit into from
Feb 17, 2023

Conversation

copybara-service[bot]
Copy link

Add a guard to avoid NaNs appearing in the conversion from rgb to hsv.

The added test shows an encountered in the wild error, where this created NaNs
in the gradient computation. The problem seems to be related to subnormals
floating point numbers.

Annoyingly, for this to be a correct explanation, it would have been fixed by
setting the epsilon value at jnp.finfo(image_rgb.dtype).smallest_normal, but
for example, in the given test case, the offending numbers are ~1e-34, so these
would not be masked (smallest_normal being ~1e-38). Setting the threshold to
jnp.finfo(image_rgb.dtype).eps (~1e-7) seems to solve the issue.

@google-cla
Copy link

google-cla bot commented Feb 17, 2023

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

@copybara-service copybara-service bot force-pushed the test_510171813 branch 2 times, most recently from 32be0e0 to 7fd3049 Compare February 17, 2023 11:55
The added test shows an encountered in the wild error, where this created NaNs
in the gradient computation. The problem seems to be related to subnormals
floating point numbers.

Annoyingly, for this to be a correct explanation, it would have been fixed by
setting the epsilon value at `jnp.finfo(image_rgb.dtype).smallest_normal`, but
for example, in the given test case, the offending numbers are ~1e-34, so these
would not be masked (`smallest_normal` being ~1e-38). Setting the threshold to
`jnp.finfo(image_rgb.dtype).eps` (~1e-7) seems to solve the issue.

PiperOrigin-RevId: 510393337
@copybara-service copybara-service bot merged commit 00bad1d into master Feb 17, 2023
@copybara-service copybara-service bot deleted the test_510171813 branch February 17, 2023 12:00
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

0 participants