Meshcat's SetObject rgba parameter behaves differently than SetProperty for "color"

sammy-tri commented 9 months ago

What happened?

When creating an object with SetObject in Meshcat (really three.js), the RGB value is translated to a hexadecimal triplet. This expression of color is treated as always being part of the SRGB color space. See:
https://github.com/mrdoob/three.js/blob/309e5f6f64c7af9087e0fb6f7cbf83a9fd2a4fef/src/math/Color.js#L100
where the color space is explicit. This results in the actual r,g,b properties in the Color for the Material being different (converted) values. When we call SetProperty for the "color" property, Meshcat calls setRGB, which does not perform a colorspace conversion by default (and there is no way to request this conversion using Meshcat's API)

Version

8936e41345

What operating system are you using?

No response

What installation option are you using?

No response

Relevant log output

No response

SeanCurtis-TRI commented 9 months ago

Presumably, sRGB values are being interpreted as linear color space values? I assume that you pick a color, and the resulting color isn't as "vibrant"?

Do you have a more concrete manifestation of the problem?

sammy-tri commented 9 months ago

Presumably, sRGB values are being interpreted as linear color space values? I assume that you pick a color, and the resulting color isn't as "vibrant"?

Yes, that seems to be the gist of the problem, hence my current workaround:

double SRGBToLinear(double c) {
  return (c < 0.04045) ? c * 0.0773993808 : std::pow(
      c * 0.9478672986 + 0.0521327014, 2.4);
}

Running that on each color channel and then calling SetProperty for "color" produces the same visual output at SetObject (with the original RGB values).

RobotLocomotion / drake