You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In the long term, we probably want to remove or thoroughly rethink the visualization categorical color mapping (see #4466). But in the short term, as part of the next theme and look and feel changes targeting the 2.10.0 and 2.11.0 releases, we want to make sure the existing color mapper chooses good values.
In #4398, we replaced a bespoke color generating utility with the standardized ouiPaletteColorBlind() function from OUI, for much more consistent colors. One problem this introduced however, is that the more rotations you pass that function, the more very light and very dark variations it produces, which don't generally look good (unless they're added alongside the primary values, such as in a visualization with > 10 series). In contrast, the previous color generator was not good at producing distinguishable colors, but it did produce colors with roughly the same luminosity.
So we want to keep the OUI palette colors, but avoid the light and dark rotations. So instead of rotating, we'll only assign one of the 10 primary visualization colors of ouiPaletteColorBlind(). (Option 2 of #4466). We've previously also considered opensearch-project/oui#856, but this is likely both simpler and better.
Note that we may want to further iterate on this solution and make sure every visualization starts with ouiPaletteColorBlind()[0], but that's out of scope for this issue, which is just about avoiding bad rotated variations.
The text was updated successfully, but these errors were encountered:
In the long term, we probably want to remove or thoroughly rethink the visualization categorical color mapping (see #4466). But in the short term, as part of the
next
theme and look and feel changes targeting the 2.10.0 and 2.11.0 releases, we want to make sure the existing color mapper chooses good values.In #4398, we replaced a bespoke color generating utility with the standardized
ouiPaletteColorBlind()
function from OUI, for much more consistent colors. One problem this introduced however, is that the more rotations you pass that function, the more very light and very dark variations it produces, which don't generally look good (unless they're added alongside the primary values, such as in a visualization with > 10 series). In contrast, the previous color generator was not good at producing distinguishable colors, but it did produce colors with roughly the same luminosity.So we want to keep the OUI palette colors, but avoid the light and dark rotations. So instead of rotating, we'll only assign one of the 10 primary visualization colors of
ouiPaletteColorBlind()
. (Option 2 of #4466). We've previously also considered opensearch-project/oui#856, but this is likely both simpler and better.Note that we may want to further iterate on this solution and make sure every visualization starts with
ouiPaletteColorBlind()[0]
, but that's out of scope for this issue, which is just about avoiding bad rotated variations.The text was updated successfully, but these errors were encountered: