这个神秘的颜色法是什么？它返回什么？ [英] What does this mysterious Color Method do? What does it return?
问题描述
也许我有太多的咖啡，也许我一直工作太长，无论如何，我对这种方法做什么，或者更确切地说，为什么和它是如何做的损失，任何人可以脱掉一些光在我身上？
public Color nextColor（）{
int max = 0，min = 1000000000，cr = 0，cg = 0，cb = 0;
for（int r = 0; r <256; r + = 4）{
for（int g = 0; g <256; g + = 4）{
for int b = 0; b <256; b + = 4）{
if（r + g + b <256 || r + g + b> 512）{
continue;
}
min = 1000000000;
for（Color c：colorTable）{
int dred = r - c.getRed（）;
int dgreen = g - c.getGreen（）;
int dblue = b - c.getBlue（）;
int dif = dred * dred + dgreen * dgreen + dblue * dblue;
if（min> dif）{
min = dif;
}
}
if（max
cr = r;
cg = g;
cb = b;
}
}
}
}
return new Color（cr，cg，cb，0x90）;
}
UPDATE
感谢大家的回应。看看程序中的方法的上下文，很明显，他们的意图是返回一个新的颜色是最远离现有的颜色集合。
感谢Sparr构建了后续功能，这个问题，我一定会根据您的建议重写上述内容。
我不太熟练的RGB颜色标度。知道上述方法的意图是检索补充？颜色到现有的颜色，将解决方案提供在 1 在我们如何看待颜色的意义上实际上是互补的？有没有更简单的方法来选择一种颜色来补充集合，或者RGB组件的数值分析是否实际产生合适的颜色？
考虑由colorTable中的点定义的伪实体在其内部具有大的中空的情况，使得nextColor选择该中空的中心中的点作为nextColor。根据你对colorTable的了解，这种情况可能非常罕见。如果预计足够稀少，并且你愿意接受一个不是最优的（假设我们使nextColor的输出是最优的）解决方案，那么一个显着的优化会呈现出来。
在除了上述之外的所有情况下，由nextColor选择的颜色将位于包围由循环定义的1 / 64-稠密色空间中的所有点的最小凸包的表面上的某处。生成该表面上的点列表比生成所有点的列表的简单循环稍微更复杂一些，但它会将您的搜索空间减少约25倍。
在绝大多数情况下，简化搜索的结果将是该凸包的一个角上的点。考虑只有那些将你的搜索空间减少到一个普通的列表（24候选人，如果我的心理几何服务我很好），可以简单地提前存储。
如果nextColor选择从那些是太接近你的colorTable，那么你可以回到运行原始类型的搜索，希望找到这种空心上面提到。该搜索的密度可以基于第一遍得到的接近程度以及从那里缩小而调整。也就是说，如果超快速搜索在colorTable中找到距离其最近邻居8个单位的nextColor，那么要做的更好，你将不得不在colorTable中找到至少16个单位的空洞。运行原始搜索步骤8，存储任何候选人超过4个单位（空心不可能与您的搜索网格对齐），然后中心半径12搜索更高密度在每个候选人。 / p>
我发现你的搜索空间的1/64密集性质（所有4的倍数）可能是由原作者为加速而设立的搜索在第一位。鉴于这些改进，您就可以避免这种折衷。
所有这些都假设您希望坚持对这种找到对比色的天真方法的改进。有更好的方法，给予等于或更多（在colorTable中的颜色是最常见的在你的用法？什么颜色出现更多的对比度对人眼？）信息。
Maybe I've had too much coffee, maybe I've been working too long, regardless, I'm at a loss as to what this method does, or rather, why and how it does it, could anyone shed some light upon me? What is the nextColor?
public Color nextColor() {
int max = 0, min = 1000000000, cr = 0, cg = 0, cb = 0;
for (int r = 0; r < 256; r += 4) {
for (int g = 0; g < 256; g += 4) {
for (int b = 0; b < 256; b += 4) {
if (r + g + b < 256 || r + g + b > 512) {
continue;
}
min = 1000000000;
for (Color c : colorTable) {
int dred = r - c.getRed();
int dgreen = g - c.getGreen();
int dblue = b - c.getBlue();
int dif = dred * dred + dgreen * dgreen + dblue * dblue;
if (min > dif) {
min = dif;
}
}
if (max < min) {
max = min;
cr = r;
cg = g;
cb = b;
}
}
}
}
return new Color(cr, cg, cb, 0x90);
}
UPDATE
Thanks for the responses everyone. Looking at the context of the method within the program it is clear that their intent was indeed to return a new Color that is "furthest away" from the set of existing Colors.
Thanks Sparr for posing the followup to this question, I will definitely rewrite the above with your advice in mind.
I am not very well versed in the RGB color scale. Knowing the intention of the above method is to retrieve a "complimentary?" color to the existing set of colors, will the solution provided in 1 actually be complimentary in the sense of how we perceive the color? Is there a simpler way to choose a color that will compliment the set, or does the numerical analysis of the RGB components actually yield the appropriate color?
Consider the case where the pseudo-solid defined by the points in the colorTable has a large "hollow" in its interior, such that nextColor selects the point in the center of that hollow as the nextColor. Depending on what you know about the colorTable, this case could be exceedingly rare. If it is predicted to be rare enough, and you are willing to accept a less than optimal (assuming we take nextColor's output to be optimal) solution in those cases, then a significant optimization presents itself.
In all cases except the above-described one, the color selected by nextColor will be somewhere on the surface of the minimal convex hull enclosing all of the points in the 1/64-dense colorspace defined by your loops. Generating the list of points on that surface is slightly more computationally complex than the simple loops that generate the list of all the points, but it would reduce your search space by about a factor of 25.
In the vast majority of cases, the result of that simplified search will be a point on one of the corners of that convex hull. Considering only those reduces your search space to a trivial list (24 candidates, if my mental geometry serves me well) that could simply be stored ahead of time.
If the nextColor selected from those is "too close" to your colorTable, then you could fall back on running the original type of search in hopes of finding the sort of "hollow" mentioned above. The density of that search could be adapted based on how close the first pass got, and narrowed down from there. That is, if the super fast search finds a nextColor 8 units away from its nearest neighbor in colorTable, then to do better than that you would have to find a hollow at least 16 units across within the colorTable. Run the original search with a step of 8 and store any candidates more than 4 units distant (the hollow is not likely to be aligned with your search grid), then center a radius-12 search of higher density on each of those candidates.
It occurs to me that the 1/64-dense nature (all the multiples of 4) of your search space was probably instituted by the original author for the purpose of speeding up the search in the first place. Given these improvements, you do away with that compromise.
All of this presumes that you want to stick with improvements on this naive method of finding a contrasting color. There are certainly better ways, given equal or more (which colors in colorTable are the most prevalent in your usage? what colors appear more contrast-y to the human eye?) information.
这篇关于这个神秘的颜色法是什么？它返回什么？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
