I am writing a tool that will attempt to determine which of the known colors is "closest" to some user-chosen color (from the full RGB gamut). I am noticing that the values returned by Microsoft's GetHue and GetBrightness appear to have the same values as the HSL Hue and the HSL Lightness values computed by the HSL and HSV article. But Microsoft's GetSaturation does not appear to consistently equate to any computed value (HSL, HSV, HSI).
Question(s)
What color model does Microsoft use for its GetHue, GetSaturation, and GetBrightness functions?
Has anyone found errors in the HSL and HSV computations?
I reviewed Chris Haas' algorithm in RGB to HSL and back, calculation problems and found that my derivation of the algorithm was flawed.
What color model does Microsoft use for its GetHue, GetSaturation, and GetBrightness functions? HSL. In the Color Dialog component, the HSL values are transformed from the range [0,1] to the range [0,240].
There do not appear to be any errors in HSL and HSV, only those that I introdiced.
Related
I have an RGB image and I converted to Lab colorspace. Now, I want to convert the image in LAB space to grayscale one. I know L NOT = Luminance.
So, any idea how to get the equivalent gray value of a specific color in lab space?
I'm looking for a formula or algorithm to determine the equivalent gray value of a color given the LAB values.
The conversion from Luminance Y to Lightness L* is defined by the CIE 1976 Lightness Function. Put another way, L* transforms linear values into non-linear values that are perceptually uniform for the Human Visual System (HVS). With that in mind, your question is now dependent on what kind of gray you are looking for, if perceptually uniform and thus non-linear, the Lightness channel from CIE Lab* is actually that of CIE 1976 and is appropriate. If you need something linear, you would have to convert back to CIE XYZ tristimulus values and use the Y channel.
So I know basically nothing about colors apart from the very basics.
I have a color I'm trying to mimic.
I copied it, stuck it in paint, and used the color feature to get the RGB HSL numbers. Great!
RGB: 0; 49; 70
HSL: 132; 240; 33
The issue: When I try to manually input them into Excel, it "autocorrects" the RGB values after I enter in the HSL, and it "autocorrects" the HSL when I re-enter the RGB.
Why is this happening? Is this just an aspect to colors I know nothing about? Some limitation on Excel?
For reference, when I put in just the RGB, I'm much closer (but not quite there) on the color I'm looking for
HSL and RGB are two ways of "translating colors" into numbers.
HSL means Hue, Saturation, Lightness.
Hue is a degree on the color wheel from 0 to 360. 0 is red, 120 is green, 240 is blue.
Saturation is a percentage value; 0% means a shade of gray and 100% is the full color.
Lightness is also a percentage; 0% is black, 100% is white.
RGB means Red, Green, Blue, each of which is given a value between 0 and 255 in Excel.
Check this tool - https://www.w3schools.com/colors/colors_hsl.asp
If you put 0, 49, 70 for HSL you would see that it gets translated to 216, 141, 141 into RGB.
Excel is following the same logic, thus once you adjust the RGB the HSL gets automatically adjusted to represent the same color.
Excel colors are confusing because they don't follow the standard
Although the first reason you may have been confused was if you didn't know that RGB and HSL are two different ways of describing colors (and that every RGB color code has an equivalent HSL color code—see examples below), a second reason many people can get confused when selecting colors in Excel particularly is:
“Frustratingly, Excel does not handle HSL in the standard way. Instead, Excel measures all the numbers where 0 is the lowest and 255 is the biggest. But, it’s a quirk we can handle.” - https://exceloffthegrid.com/convert-color-codes/
“This approach assumes that each of your HSL values can be express in the range of 0 to 255. If, however, your HSL values are either an angle (for hue) or a percentage (for saturation and luminance), then you'll need to convert them manually before entering them in step 6. You can convert an angle value by multiplying the angle by 255 and then dividing by 360. Percentages can be converted by multiplying them by 2.55.” - https://excelribbon.tips.net/T013535_Converting_HSL_to_RGB.html
“To change the lightness (adding white) or darkness (adding black), drag your selection up and down the luminance scale on the right. Notice that the Lum value increases as the color gets lighter. Full luminance is 255 (white), and setting Lum to 0 results in black regardless of the hue and saturation settings.” - https://support.microsoft.com/en-us/office/choosing-colors-in-the-colors-dialog-box-c3d59ddf-65a7-4e62-aad7-f7b8d7684a2d
Examples of converting RGB color codes to HSL
rgb(0, 49, 70) = hsl(198, 100%, 14%)
These independent sites agree with Google that that RGB code converts to that HSL code:
https://colorpicker.me/#003146
https://hslpicker.com/#003146
So if someone told you that rgb(0, 49, 70) was equivalent to hsl(132, 240, 33), they were mistaken (even when using Excel's non-standard way of calculating HSL).
Is there a dataset that maps each of the ~16M RGB or hex color values to a general color family/category - e.g. red, purple, orange, beige, brown, etc. - that I could access programmatically or load into a database or JSON document to cross-refence the color codes against? The use case is to classify the results of PIL color detection of swatch files into a small set of color pickers for a shopping site. It would also work if the mapping is a bit more granular, say 100-200 categories, since it would be easy enough to map those to my target 10-15 myself. I have some knowledge of kNN classification and will work with that if I have to, but it would be so much easier to use a static mapping if one already exists.
You can use a table such as the one in X11
http://www.astrouw.edu.pl/~jskowron/colors-x11/rgb.html
In order to find color proximity, it's best to transform the colors to Lab color space first, so that euclidean distances have more meaning, and then nearest neighbor would give good results.
You could convert from RGB to CIE Lab color space wherein Euclidian distance between two color selections is perceptually more meaningful. Here is the link to all relevant color space transformation formulae used in OpenCV's color conversion method (cvtColor): http://docs.opencv.org/modules/imgproc/doc/miscellaneous_transformations.html
Since your use case is to compare two swatches, I would advise you to use texture descriptors (http://www.robots.ox.ac.uk/~vgg/research/texclass/with.html) in addition to color information for better results.
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 want to incrementally rotate around the color wheel hopping to the opposite side each turn. I have an undefined number of clients to represent on a kendo chart and I want to ensure that they are all identifiable against their immediate neighbours. Can anyone pin down a mathematical relationship between colours on opposite sides of the colour wheel? I am of course working on this myself but I thought it an interesting little problem that you guys might enjoy with me.
It would be easier to do this type of conversion in the HSL or HSV color space, rather than RGB (aka hex values). Then to get the opposite point on the wheel just follow the formula:
hue = (hue + 180) % 360
So starting with hsl(0, 80%, 20%) would yield hsl(180, 80%, 20%) etc. The easiest way to convert a given RGB value to an RGB value on the opposite point would be to convert RGB to HSL or HSV, do the shift, and convert that back to RGB. The formulas for that can be found here: http://en.wikipedia.org/wiki/HSL_and_HSV
Modern browsers support HSL natively, so maybe some of this complexity can be avoided and you would never need to muck with RGB values in the first place. http://caniuse.com/css3-colors
The color wheel is based on the HSV color space, where the hue coordinate represents your angle on the color wheel. You need to convert RGB colors into HSV, perform your rotation on the hue coordinate, then convert back to RGB.