Question

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

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

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

为此目的，最好的桌面布局是什么？

Answer 1

你可以这样做：

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

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

我仍然怀疑数据库访问速度比计算慢，所以我想的是“过早优化是所有邪恶的根源”。

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

Answer 2

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

预先计算数据库中所有颜色的HCL向量，并存储一个将颜色ID映射到其HCL向量的表。
该表格应使用MySQL Spatial Extensions存储，以便您查询某个点的邻居。
选择新颜色后，将其转换为HCL，并在HCL空间中查询其点的邻居。
如果需要缓存，我会缓存粗粒度颜色，因此用户有可能重新访问之前选择的颜色。

Answer 3

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

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

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

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

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

Answer 4

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

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

虽然似乎只有有限数量的组合？看起来你可以为每个组合做一次数学运算，只需要一个查找表吗？

Answer 5

以下是我的建议：

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

在MySQL中存储距离

5 个答案: