Using Element::get<Color> has surprising defaults

[osrf-migration]

Original report (archived issue) by SeanCurtis-TRI (Bitbucket: SeanCurtis-TRI).

---

When parsing a <material> tag for (e.g.,) diffuse color information, one can do the following (assuming that material_element is an sdf::Element):

Color default_color(0.25, 0.5, 0.75, 0.8);
material_element.Get<Color>("diffuse", default_color);

The specification suggests that the corresponding tag should look like:
<diffuse>r g b a</diffuse>

However, the following tags produce the following colors:
<diffuse>1</diffuse --> 1 0 0 1
<diffuse>1 0.25</diffuse> --> 1 0.25 0 1
<diffuse>1 0.25 0.5</diffuse> --> 1 0.25 0.5 1
<diffuse>1 0.25 0.5 0.75 2</diffuse> --> 1 0.25 0.5 0.75

The rules I infer are:

1. If a is missing, use the default value 1.
2. if r, g, or b are missing, use the default value 0
3. If there are two many values, simply truncate.

I think this is incredibly counter-intuitive and not strictly helpful. One can make solid arguments that supplying rgb (in place of rgba) is a reasonable overload. But all of the rest seem kind of insane.

[osrf-migration]

Original comment by SeanCurtis-TRI (Bitbucket: SeanCurtis-TRI).

---

Also, out-of-range values get treated....strangely.

Alpha seems to simply get clamped to the range [0, 1]
R, G, & B get a different treatment. They are clamped to zero if negative and set to i/255 if larger than 1 (with no guarantees that the resultant value is still in the range [0, 1]).

[EricCousineau-TRI]

Still awkward in RobotLocomotion/drake#14705
\cc @SeanCurtis-TRI