I have to find the nearest color. For example, I have two colors colorA1, colorA2 which are nearly same color. And also I have other color colorB1.
And I need such a method:
Color getNearestColor(colorA1, colorA2, colorB1). This method should give me the colorB2 which is calculated by using the difference of colorA1 and colorA2, then using their distance it should give me colorB2 which has the same distance as in colorA1 and colorA2.
Can you give some ideas how to implement it?
To find the nearest colour, you need a definition of "near", so a metric.
In Wikipedia you will find different metrics of color differences.
Personally I would use the 2*R*R + 4*G*G + 3*B*B. (no need for square roots, you will just compare same metrics). Easy to calculate, you can use just integers (if you use 32 bit integers, you will have no overflow).
Then find which colour has the smallest differences between your target colour.
The other methods are more precise, but in that case "RGB" is not enough. You need to know which colour space are using (probably you are in sRGB).
Related
Is it possible to find the nearest PMS color of any CMYK/RGB/HSL color?
I understand that PMS is an arbitrary color system (not a space) and it's not possible to do conversions using algorithms.
I have seen (some, examples) on the web, where people who developed the tools managed to do the "conversion" form CMYK to PMS.
I'm wondering if there is a lookup technique/reference that I can use.
––
Update
I am not sure if this would help in finding PMS color...
To find matches, the total sum of the differences (delta, Δ) of the CMYK color components between the input CMYK color and the matched PANTONE color is calculated for the entire table of PANTONE colors. This list is then sorted by increasing delta, so that the matches with the smallest difference are on top. Note that because the delta is not weighted, you may get matches that are optically off.
Can anyone show me a (language agnostic) way to assign a colour value to a bit field so that comparatively similar bit fields have a similar colour to each other. So for example
01100111
And
01110111
Are close in colour relatively. But
11011001
Is further away
By "further away" I mean distant in hue, saturation, brightness, etc...
If we have an array of all the bit fields then it would be possible to compare them all then produce a set of colours. But what if we don't know and we want one bit field to always be represented by one colour?
Or else we could pre compute all possible colour values for a given number if bits. How would I go about doing that?
You cannot do this, because (essentially) there are only 2 dimensions to your perceived color space, while treating the bits independently as you suggest makes a separate dimension for each bit.
I have an image and I am picking colors by RGB (data sampling). I select N points from a specific region in the image which has the "same" color. By "same" I mean, that part of the image belongs to an object, (let's say a yellow object). Each picked point in the RGB case has three values [R,G,B]. For example: [120,150,225]. And the maximum and minimum for each field are 255 and 0 respectively.
Let's assume that I picked N points from the region of the object in the image. The points obviously have different RGB values but from the same family (a gradient of the specific color).
Question:
I want to find a range for each RGB field that when I apply a color filter on the image the pixels related to that specific object remain (to be considered as inliers). Is it correct to find the maximum and minimum from the sampled points and consider them as the filter range? For example if the max and min of the field R are 120 ,170 respectively, can it be used as a the range that should be kept.
In my opinion, the idea is not true. Because when choosing the max and min of a set of sampled data some points will be out of that range and also there will be some point on the object that doesn't fit in this range.
What is a better solution to include more points as inliers?
If anybody needs to see collected data samples, please let me know.
I am not sure I fully grasp what you are asking for, but in my opinion filtering in RGB is not the way to go. You should use a different color space than RGB if you want to compare pixels of similar color. RGB is good for representing colors on a screen, but you actually want to look at the hue, saturation and intensity (lightness, or luminance) for analysing visible similarities in colors.
For example, you should convert your pixels to HSI or HSL color space first, then compare the different parameters you get. At that point, it is more natural to compare the resulting hue in a hue range, saturation in a saturation range, and so on.
Go here for further information on how to convert to and from RGB.
What happens here is that you implicitly try to reinvent either color indexing or histogram back-projection. You call it color filter but it is better to focus on probabilities than on colors and color spaces. Colors of course not super reliable and change with lighting (though hue tends to stay the same given non-colored illumination) that's why some color spaces are better than others. You can handle this separately but it seems that you are more interested in the principles of calculating "filtering operation" that will do segmentation of the foreground object from background. Hopefully.
In short, a histogram back-projection works by first creating a histogram for R, G, B within object area and then back-projecting them into the image in the following way. For each pixel in the image find its bin in the histogram, calculate its relative weight (probability) given overall sum of the bins and put this probability into the image. In such a way each pixel would have probability that it belongs to the object. You can improve it by dividing with probability of background if you want to model background too.
The result will be messy but somewhat resemble an object segment plus some background noise. It has to be cleaned and then reconnected into object using separate methods such as connected components, grab cut, morphological operation, blur, etc.
I'm trying to make a bar with gradient color updownward, I set 3 points as stated in the bar. Now the picture seems good, but I don't know how to automatically generate these color mathematically, by RGB or HSB? I'm having trouble with the rule of this kind of art thing.
I was intending to do it with RGB but I found it hard to do. But with HSB, I changed "S" and it makes a little sense as shown in picture.
My question is: How to calculate these three colors based on ONE given color, makes the gradient natural?
Thanks in advance, this has nothing to do with code but I think it definitely has a mathematical solution(formula).
I think there's no general rule for how to do this and different possibilities to get to a (subjectively pleasing) result.
I copied your colors here for analysis but didn't find a pattern in your choice. My solution would be to find a pleasing distance of (relative) luminance. To adabt to your example I chose one arbitrary color, then increased the Lum value by 18% for the second color and for the third one I subtracted 10% Lum again.
Do you like this solution?
Let's say that I have a list of valid color values like [0x67FF82, 0x808080, 0xffffff, ...] and given an input color, in hex, I want to find which color in the list of acceptable colors that the input color is closest to.
My thought is that I'd find the color in which the absolute value of the difference of the red, green, and blue values is smallest. Is this correct?
It sounds like you're looking for a way to quantify the "distance" between colors - in math, they'd call it a metric. Many people are intuitively pretty comfortable with the Euclidean metric for example - it's simply the distance between two points as measured with a ruler. In the case of colors, things are more complicated because of subjective perception of different colors.
There's a pretty mathy wikipedia article about color difference, which includes links to different implementations.
The difference or distance between two colors is a metric of interest in color science. It allows people to quantify a notion that would otherwise be described with adjectives, to the detriment of anyone whose work is color critical. Common definitions make use of the Euclidean distance in a device independent color space.
In particular, there's Python Colormath, an implementation in python that converts between different color encodings and also seems to have a function for calculating the distance between two colors. If you happen to be coding in python, that sounds helpful, although I unfortunately don't have any personal experience with that tool. There's also similar resources available for MATLAB and Excel provided by the authors of CIE2000, a leading color-difference formula.