Page MenuHome

Fix T68076: Color Correction node generates NaN
ClosedPublic

Authored by Jacques Lucke (JacquesLucke) on Jan 28 2020, 11:42 AM.

Details

Summary

This is the same fix that the GammaOperation uses.

Two alternative solutions:

  • Clamp r, g and b to make sure they are >= 0.
  • Check r * gain + lift > 0.0f instead of just r > 0.0f.

I'm not sure which solution is best.

Diff Detail

Repository
rB Blender

Event Timeline

If it's any help, Cycles has a safe_powf function in util_math.h. Maybe this could be used Blender side too.

ccl_device float compatible_powf(float x, float y)
{
#ifdef __KERNEL_GPU__
  if (y == 0.0f) /* x^0 -> 1, including 0^0 */
    return 1.0f;

  /* GPU pow doesn't accept negative x, do manual checks here */
  if (x < 0.0f) {
    if (fmodf(-y, 2.0f) == 0.0f)
      return powf(-x, y);
    else
      return -powf(-x, y);
  }
  else if (x == 0.0f)
    return 0.0f;
#endif
  return powf(x, y);
}

ccl_device float safe_powf(float a, float b)
{
  if (UNLIKELY(a < 0.0f && b != float_to_int(b)))
    return 0.0f;

  return compatible_powf(a, b);
}

@Charlie Jolly (charlie) thanks for the info. Not sure if that is necessary here. Allowing powf(negative_number, integer) in the context of the color correction node does not seem to be correct.

I'm not sure what the best solution is. Using this operation on negative values doesn't make much sense to me, so leaving them untouched entirely seems reasonable.

This revision is now accepted and ready to land.Jan 31 2020, 6:07 PM