1

我的数据库中有一个“颜色”表。

用户通过用户界面输入一种颜色，后端搜索颜色表中存在的最相似的颜色，计算颜色在 HCL 空间中的距离。

我将实现一个缓存算法，它应该存储先前计算的颜色距离之间的距离，以避免重复的数学运算。

用于此目的的最佳表格布局是什么？

4

5 回答 5

3

你可以这样做：

table colors(r,g,b)
table colordistance(user_r,user_g,user_b,r,g,b,distance)

但是您是否希望您的用户继续输入相同的数字？？？如果只包含最接近的颜色，则此表中的最大行数为 16777216。

我仍然怀疑数据库访问比计算慢，所以我在想这句话“过早优化是万恶之源”。

我会在没有任何计算缓存的情况下运行它，直到我将其视为一个实际问题。

于 2009-08-11T07:16:25.060 回答
3

正如 Osama 所说，这看起来像是过早的优化。根据您对算法的描述，我会：

  • 预先计算数据库中所有颜色的 HCL 向量，并存储一个将颜色 id 映射到其 HCL 向量的表。
  • 该表应该使用MySQL Spatial Extensions存储，它允许您查询一个点的邻居。
  • 选择新颜色后，将其转换为 HCL，并在 HCL 空间中查询其点的邻居。
  • 如果需要缓存，我会缓存粗粒度的颜色，因此用户有机会重新访问以前选择的颜色。
于 2009-08-11T08:00:25.847 回答
1

我假设您的颜色“距离”计算如下：

sqrt((r1-r2)^2 + (g1-g2)^2 + (b1-b2)^2)

假设您使用 8 位像素，则表中将有 (256^3)^2 个不同的映射。这是很多表空间。（你可能会压缩它很多，但是......看下一点。）

您需要考虑的另一件事是查找颜色距离的数据库查找成本与进行计算的成本。我的猜测是数据库查找需要一毫秒或更长时间，但度量计算应该需要 1 微秒或更短时间。

总而言之，使用数据库表对我来说听起来是个坏主意。

于 2009-08-11T07:23:00.257 回答
0

我对 HCL 不太熟悉，但根据Color::Similarity::HCL的描述，似乎需要两种颜色作为距离的输入。

所以我认为至少应该存储两组RGB以及它们之间的相应距离。我不确定您的用例，但如果选择了选择范围，您可能还想存储用户选择。

似乎只有有限数量的组合？似乎您可以为每个组合做一次数学运算，然后只需要一个查找表？

于 2009-08-11T07:06:50.697 回答
0

这是我推荐的：

table colors(color_id, color_name, r, g, b)

table color_distances(color_1_id, color_2_id, distance)

索引：PRIMARY (color_1_id, color_2_id) INDEX (color_1_id, distance, color_2_id)

color_distances 将包含所有可能的 color_id 组合，并且只会根据需要进行更新。

选择会很简单：

SELECT similar_colors.*
FROM colors as similar_colors, color_distances
WHERE color_distances.color_1_id = <selected_color_id>
ORDER BY color_distances.distance ASC
于 2009-08-11T07:52:26.097 回答