稳定的随机颜色算法

Olm*_*lmo 5 algorithm rgb gdi colors hsv

在这里,我们有一个有趣的真实算法要求涉及颜色.

  1. N 漂亮的颜色:为了绘制漂亮的图表(即:饼图),我们需要选择一组随机的N颜色,这些颜色"足够不同"并且看起来很好.这可以通过固定亮度和饱和度并逐步调整色调来实现360/N.
  2. 稳定的颜色分配:给定Pie_1带扇区标记('A','B','C')和Pie_2带扇区标记('B','C','D'),如果扇区的颜色会很好Pie_1和Pie_2上的B和C相同.如果扇区被移除或随着时间的推移添加到图表中,这将有助于防止混淆.标签是唯一稳定的东西.
  3. 允许硬编码颜色:算法应允许硬编码标签 - >颜色关系作为输入,但会为其余标签计算颜色(根据规则1和2).

我认为这个算法即使看起来很特别,也会在不止一种情况下发挥作用.

有任何想法吗?

更新: Eric是正确的,因为当新标签出现和消失时,不可能保证每个标签的颜色稳定性.但我很高兴它是否"足够稳定",即颜色变化最小化.

我想的是:

  1. 每个标签使用散列(标签)%360获得随机色调值
  2. 为了保证生成的色调足够不同,我们将色调圆以固定的步长(即:)划分,2*N并尝试将先前的色调值"舍入"到新的差异值.
  3. 在不同标签达到相同的圆形色调值的情况下,我们以某种方式打破关系并将点移动到其他位置.

但这留下了硬编码颜色的问题.

Eri*_* J. 4

您可以使用色轮算法选择一组看起来不错的随机颜色。这是一个相关的 SO 问题和实施指南,或者谷歌搜索许多其他问题。

您可以使用标签散列之类的东西作为色轮上的起点,以确保稳定性。这也满足 3. 如果您有一个覆盖机制来声明特定标签哈希值应对应于色轮上的特定起点。

编辑:

色轮允许您选择一个主起点(例如(散列(A)% 360)并确保其他两种颜色(B,C)与 A 一起使用时“不错”。B 和 C 由 A 确定。如果您稍后可以有一个饼图 (B, Y, Z),B 将设置为 (hash(B) % 360) 并且与 (A, B, C) 情况下的情况不同。

如果您可以在饼图上任意混合标签,则没有任何算法可以确保它们总是看起来很好。这是一个简单的证明:

选择A、B、C,使它们在一起看起来很好。

现在让A以任意颜色Z出现

你当然可以为 Z 选择一些颜色,这样 A 和 Z 就会发生冲突。

您只能保证某组颜色搭配在一起效果很好,并且选择同一组颜色会再现相同的颜色。

您可以使用第一个标签的哈希值作为轮子上的起点 (hash(A)),也可以组合哈希值 (hash(A) + 31*hash(B) + 31*31*hash(C) )。乘以 31(质数)是 Java 世界中的一种方法,有助于确保在组合多个哈希时获得更好的数学分布。