I need to compare color lightness by their hex values.
I am sure that RGB FFFFFF (white) is lighter then 000000 (black). I am also sure that FFFF00 is lighter than FF0000.
But what about other values in between? Which would be the "lightest" in each of these cases?
FF00FF and 00FFFF
112233, 221133, 332211
Is there a pattern to determine which color is lighter?
Split it in RGB components and decide for each comopent what the lightness factor is.
I.e. if you think red is generally 'lighter' than blue then that factor is different.
I think these factors can be quite subjective.
If you don't want to use these factors, just add all values of the RGB components.
Maybe the following story helps (or not):
http://scienceblogs.com/mixingmemory/2006/12/does_red_weigh_more_than_blue_1.php
Related
What is the relationship between color spaces (RGB, XYZ) and the color matching function? Let's say we have some color matching function in the color space XYZ (3 row matrix). We also have the transformation matrix which translates from XYZ coordinates to RGB coordinates.
My understanding is that there is some visual input, which is made up of the color spectrum S(y). The human eye does not see the world - it only sees its interpretation of the world. The human eye has 3 cone types LMS, each of which is responsible for processing RED, GREEN, or BLUE. The human eye sees the spectral color only because it's eye sums over RED, GREEN, BLUE vector, and this sum matches the color of the input. In order to match the color, there is a color matching function, which takes the input spectrum and produces the weights by which to multiply the primary RED, GREEN, BLUE color vector. These then get added and their output visually matches the spectral input, even though the spectrum had many many frequencies added, while the human eye was only adding 3. So we went from HUGE space to space where we can describe all with 3 vectors, summed as dictated by the color matching function.
The spectral input, color primaries, and color matching functions behave as described above and can be summarized in this formula:
where pi is the 3d vector of primary colors, c - color matching function is also a vector of 3 components, and finally s is the spectral input.
We have XYZ color space, and a corresponding color matching function which does what is described above. We are then given matrix T, which transforms XYZ coordinates to RGB coordinates. We already know T, and we need to use it to produce a new color matching function for the RGB color space.
I do not understand how the color space relates to choice of primaries pi(λ) and the choice of color functions ci(λ1).
I have been trying to understand about colours from months and after some research, i believe I have some insights which probably can help me answer your question.
I do not understand how the color space relates to choice of primaries
pi(λ)
Primaries are nothing but the wavelength of the colors that we choose to use for making all the other colors in space and that also defines the gamut of the colour space. So if you play with the applet provided in the link that is given below you can see that the whole gamut in the colour space changes when you change your primary.
Have a look at Alternative primaries and gamuts section.
Now I do not know how much you understand the RGB and XYZ or what do you mean when you say RGB here (assuming you are referring to sRGB gamut values); XYZ are actually Tristimulus values which are called rho, beta and gamma as shown in the image above and just for simplicity XYZ are converted to xy space from where you get your standard sRGB gamut.
Please go through this if you are interested in understanding how colour sensors work and converting sensor values to XYZ matrix
Please comment if I have missed any information or answer needs editing.
I think lots of issues with color selection are due technical problems people had to solve. Usually you are not trying to reproduce colors as accurately as possible, but to make them pleasant looking, cheap, fast to calculate on cpu.... If someone watches plains of New Zealand on TV he is very unlikely to know they really look like, but almost certainly wants to enjoy the picture and pay little for it.
Several reasons why you might want to use different color matching functions might include:
You are taking pictures under non-white light and you want your picture to look natural.
You are taking underwater pictures and want to compensate for the fact that water attenuates different frequencies at different speeds.
Your sensor is not perfect and you want to compensate for that.
On the other hand you might want to change your primaries due to some reason. For example your images might be taking a picture of a scene with limited amount of colors. By nudging your primaries a little you might get a "fuller" picture.
Finally sometimes you just have to compensate for some of the limitations you have with your devices. Your phosphorus on CRT TV will impose some restrictions. So will the noise in air when transmitting using PAL. On the other hand if you go digital you might be forced to have less than 36 bits per pixel. In that case you will have to make compromises and this will give you opportunity to lose as little as possible.
If you want a short tutorial visit Cambridge in colour.
Here is a Szeliski's textbook on photography, look at chapters 1 2 and 10.
Poyton has list of common transformations.
I would like to change smoothly the background color of a view over time.
Choosing 2 colors c1 and c2, it is easy in the rgb space to make a color function of the time c(t) = t.c1 + (1-t).c2, which will be a gradient between the two
However the rgb space is 3D and I am looking for a way to enumerate all colors smoothly.
I know there are billions of colors possible but coding RGB on 4x4x4 bits would be ok for my project.
My question is independent of the choice of the programming language
I have tried things like (pseudo code / Python)
for red in xrange(16):
for green in xrange(16):
for blue in xrange(16):
color = rgb(red, green, blue)
however this is not smooth at all, it is like a "step function" if you see what I mean (color will go from plain green to no green at all and a little red for instance)
Any idea how to do that ?
In that case I think you're better of with the HSV values of a color. You can use the same tactic and change only one of these HSV values at a time, to make the color shift more fluently.
Check this out (HSV)
EDIT:
After looking a bit further, I found this argument why NOT to use HSV.
This might be a good solution to your problem:
Solution
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.
I have two color values in HSI (Hue Saturation and Intensity) and I want a number which represents the visual difference between the two colors. Hue is a number between 0 and 360 inclusive. Saturation is 0 to 1 and Intensity is 0 to 1.
Lets consider for example Red and Blue at Saturation of 100% and Intensity of 100%.
At this website is a way to display the color by entering in the following text.
red is:
hsv 0, 100%, 100%
blue is:
hsv 240, 100%, 100%
Clearly these are two very different colors, and so a simple way I could try to calculate the difference between colors is to use the Hue component and calculate the absolute difference in hue which would be 120 (360-240) since 360 is also equal to 0 in hue.
The problem arises where the Saturation or Intensity is very dark or light, consider a very dark red and blue.
dark red is:
hsv 0, 100%, 20%
dark blue is:
hsv 240, 100% 20%
Obviously the visual difference between these two colors is less than the bright red and blue colors, as a human would state if asked to compare the differences. What I mean here is, ask a friend "Which pair of colors is most different?" they will likely say the top bright red blue.
I am trying to calculate the difference between two colors as a human would notice. If a human being looked at two colors a and b, then two colors c and d, he could notice which ones are the most different. Firstly if the colors are bright (but not too bright) then the difference is hue based. If the colors are too bright such as white or too dark such as black or too grey then the differences are smaller.
It should be possible to have a function diff where x=diff(a,b) and y=diff(c,d) yields x and y, and I can use x and y to compare the differences to find the most different color or least different color.
The WCAG2.0 and 1.0 guidelines both make reference to different equations on perception of color difference:
contrast ratio (http: //www.w3.org/TR/2008/REC-WCAG20-20081211/Overview.html#contrast-ratiodef)
brigtness difference and 3. color difference (http://www.w3.org/TR/AERT#color-contrast).
I tried the Delta-e method(http: //colormine.org/delta-e-calculator/) but it is quasimetric so the difference measurement may change depending on the order you pass the two colors. If in your example you expect diff(a,b) to always equal diff(b,a) then this is not what you want(there may be different algorithms under this name that aren't quasimetric but I haven't looked into it past that site).
I think that the color difference metric is the closest to matching my expectations of color difference measurements. For your example it will yield that diff(a,b) > diff(c,d)
You can test it out for yourself using the tool at this website: http://www.dasplankton.de/ContrastA/
The general answer seems to be what David van Driessche said, to use Delta E. I found some Java code here: https://github.com/kennyliou/GAI
This is a answer to the question, may not be the best answer.
how to get RGB values in percentage in photoshop.
and is cmyk percentage values are similar to RGB?
RGB and CMYK are different color modes.
RGB colors are screen colors. It is expressed in absolute values, usually in integer values from 0 to 255, representing the brightness on the screen. The exact range of values depends on the color depth of the image. The higher the value, the more light of that color is added, so the highest color is white.
CMYK colors are printing colors. They are used to represent the amount of ink used for a pixel. This is no absolute value, because it is merely a ratio between the color components. The higher the value, the darker it gets. 100% of each is (near) black, although real black is usually constructed by using 100% of K (key) and about 30% of each of the other components.
integer values from 0 to 255 are for 8 bit color, in the day of 16 or 32 bit color it would make sense to be able to view rgb as percentage values.
this is being added to Adobe lightroom currently does percentaes unless you're in the develop module, in soft proof mode