Related
I intend to find a distance metric between two colours in HSV space.
Suppose that each colour element has 3 components: hue, saturation, and value. Hue is ranged between 0 to 360, saturation is ranged between 0 to 1, and value is ranged between 0 to 255.
Also hue has a circular property, for example, 359 in hue is closer to 0 in hue value than 10 in hue.
Can anyone provide a good metric to calculate the distance between 2 colour element in HSV space here?
First a short warning: Computing the distance of colors does not make sense (in most cases). Without considering the results of 50 years of research in Colorimetry, things like the CIECAM02 Color Space or perceptual linearity of distance measures, the result of such a distance measure will be counterintuitive. Colors that are "similar" according to your distance measure will appear "very different" to a viewer, and other colors, that have a large "distance" will be undistinguishable by viewers. However...
The actual question seems to aim mainly at the "Hue" part, which is a value between 0 and 360. And in fact, the values of 0 and 360 are the same - they both represent "red", as shown in this image:
Now, computing the difference of two of these values boils down to computing the distance of two points on a circle with a circumference of 360. You already know that the values are strictly in the range [0,360). If you did not know that, you would have to use the Floating-Point Modulo Operation to bring them into this range.
Then, you can compute the distance between these hue values, h0 and h1, as
hueDistance = min(abs(h1-h0), 360-abs(h1-h0));
Imagine this as painting both points on a circle, and picking the smaller "piece of the cake" that they describe - that is, the distance between them either in clockwise or in counterclockwise order.
EDIT Extended for the comment:
The "Hue" elements are in the range [0,360]. With the above formula, you can compute a distance between two hues. This distance is in the range [0,180]. Dividing the distance by 180.0 will result in a value in [0,1]
The "Saturation" elements are in the range [0,1]. The (absolute) difference between two saturations will also be in the range [0,1].
The "Value" elements are in the range [0,255]. The absolute difference between two values will thus be in the range [0,255] as well. Dividing this difference by 255.0 will result in a value in [0,1].
So imagine you have two HSV tuples. Call them (h0,s0,v0) and (h1,s1,v1). Then you can compute the distances as follows:
dh = min(abs(h1-h0), 360-abs(h1-h0)) / 180.0
ds = abs(s1-s0)
dv = abs(v1-v0) / 255.0
Each of these values will be in the range [0,1]. You can compute the length of this tuple:
distance = sqrt(dh*dh+ds*ds+dv*dv)
and this distance will be a metric for the HSV space.
Given hsv values, normalized to be in the ranges [0, 2pi), [0, 1], [0, 1], this formula will project the colors into the HSV cone and give you the squared (cartesian) distance in that cone:
( sin(h1)*s1*v1 - sin(h2)*s2*v2 )^2
+ ( cos(h1)*s1*v1 - cos(h2)*s2*v2 )^2
+ ( v1 - v2 )^2
In case you are looking for checking just the hue, Marco's answer will do it. However, for a more accurate comparison considering hue, saturation and value, Sean's answer is the right one.
You can't simply check the distance from hue, saturation and value equally, because hue is a circle, not a normal vector. It's not like RGB where red, green and blue are vectors
PS: I know I am not giving any new solutions with this post, but Sean's answer really saved me and I wanted to acknowledge it besides upvoting since it is not the top answer here.
Lets start with:
c0 = HSV( h0, s0, v0 )
c1 = HSV( h1, s1, v1 )
Here are two more solutions:
(Helix Length)Find the length of curve in euclidean space:
x = ( s0+t*(s1-s0) ) * cos( h0+t*( h1-h0 ) )
y = ( s0+t*(s1-s0) ) * sin( h0+t*( h1-h0 ) )
z = ( v0+t*(v1-v0) )
t goes from 0 to 1.
Note: h1-h0 is not just subtraction it is modulus subtraction.
This can be optimized by rotation and then use: h0=0, and h1 = min(abs(h1-h0), 360-abs(h1-h0))
(Helix Length over RGB)Same as above but convert above curve in to RGB instead to euclidean space then calculate arc length.
And again convex combination by coordinate of HSV colors, each point on HSV-line convert to RGB.
Calculate the length of that line in RGB space with euclidean norm.
helix_rgb( t ) = RGB( HSV( h0+t*( h1-h0 ), s0+t*(s1-s0), v0+t*(v1-v0) ) )
t goes from 0 to 1.
Note: h1-h0 is not just subtraction it is (more than) modulus subtraction e.g.
D(HSV(300,50,50),HSV(10,50,50)) = D(HSV(300,50,50),HSV( 0,50,50)) + D(HSV( 0,50,50), HSV(10,50,50))
Comparison of metrics:
RGB(0,1,0) is referent point and calculate distance to color in right-down corner image.
Color image is generated by rule HSL([0-360], 100, [1-100] ).
EM is short from Euclid with Modulo as Marco13 propose with Sean Gerrish's scale.
Comparison of solutions over HSI, HSL and HSV, there are also distance in RGB and CIE76(LAB).
Comparing EM to other solutions like Helix len, RGB2RGB, CIE76 appears that EM give acceptable result at very low cost.
In https://github.com/dmilos/color.git it is implemented EM with arbitrary scaling.
Example:
typedef ::color::hsv<double> color_t; // or HSI, HSL
color_t A = ::color::constant::orange_t{}; \
color_t B = ::color::constant::lime_t{}; \
auto distance = ::color::operation::distance<::color::constant::distance::hue_euclid_entity>( A, B, 3.1415926/* pi is default */ );
I have not been able to find much info on the RGBW color system, other than that the final W stands for 'white'. I thought you could form white perfectly well with just red, green and blue, so I do not understand the function of white here.
Searching StackOverflow, I've found this question about converting between RGB and RGBW. Both answers suggest this 'algorithm' for conversion:
// RGBW from RGB
R, G, B, W = R, G, B, min(R, G, B) // i.e. W=min(R,G,B)
// RGB from RGBW
R, G, B = R, G, B // throw away the W
This doesn't only look useless, it's also not true. My Android phone, running Cyanogenmod, has a light sensor that outputs RGBW (cat /sys/class/sensors/light_sensor/lux) and the white value is definitely not min(r,g,b). I've made a chart with the values:
(The X axis is time.)
The black line represents the white value (an actually white line would be rather difficult to see), the other colors are accurate (i.e. red line is the measured red value, etc.). From sight, I cannot determine any relation between white and the other colors, so it probably serves a function. I just cannot understand which.
It's this sensor: http://www.capellamicro.com.tw/EN/product_c.php?id=68&mode=16
And here is the source code that controls the sensor: https://github.com/mozilla-b2g/kernel-android-galaxy-s2-ics/blob/master/drivers/sensor/cm36651.c#L605-L630
That is all I've been able to figure out, but nothing contains info on what this white value represents.
That exactly it – you can't form white perfectly using only RGB LEDs. This is because the RGB colorspace is a small, pale fraction of the CIE-1931 XYZ space, and it’s distorted: incrementing an RGB values’ “R” by 1 is not at all qualitatively the same as incrementing its “G” value or “B” value, for example.
Just do a side by side comparison and the difference will be very, very clear. You can google “True white RGB led” and you'll learn a lot more; a good introduction is here: http://www.ledsmagazine.com/articles/print/volume-10/issue-6/features/understand-rgb-led-mixing-ratios-to-realize-optimal-color-in-signs-and-displays-magazine.html
This is a geometrical question based on a programming problem I have. Basically, I have a MySQL database full of latitude and longitude points, spaced out to be 1km from each other, corresponding to a population of people who live within the square kilometer around each point. I then want to know the relative fraction of each of those grids taken up by a circle of arbitrary size that overlaps them, so I can figure out how many people roughly live within a given circle.
Here is a practical example of one form of the problem (distances not to scale):
I am interested in knowing the population of people who live within a radius of point X. My database figures out that its entries for points A and B are close enough to point X to be relevant. Point A in this example is something like 40.7458, -74.0375, and point B is something like 40.7458, -74.0292. Each of those green lines from A and B to its grid edge represents 0.5 km, so that the gray circle around A and B each represent 1 km^2 respectively.
Point X is at around 40.744, -74.032, and has a radius (in purple) of 0.05 km.
Now I can easily calculate the red lines shown using geographic trig functions. So I know that the line AX is about .504 km, and the distance line BX is about .309 km, for whatever that gets me.
So my question is thus: what's a solid way for calculating the fraction of grid A and the fraction of grid B taken up by the purple circle inscribed around X?
Ultimately I will be taking the population totals and multiplying them by this fraction. So in this case, the 1 km^2 grid around corresponds to 9561 people, and the grid around B is 10763 people. So if I knew (just hypothetically) that the radius around X covered 1% of the area of A and 3% of the area of B, I could make a reasonable back-of-the-envelope estimate of the total population covered by that circle by multiplying the A and B populations by their respective fractions and just summing them.
I've only done it with two squares above, but depending on the size of the radius (which can be arbitrary), there may be a whole host of possible squares, like so, making it a more general problem:
In some cases, where it is easy to figure out that the square grid in question is 100% encompassed by the radius, it is in principle pretty easy (e.g. if the distance between AX was smaller than the radius around X, I know I don't have to do any further math).
Now, it's easy enough to figure out which points are within the range of the circle. But I'm a little stuck on figuring out what fractions of their corresponding areas are.
Thank you for your help.
I ended up coming up with what worked out to be a pretty good approximate solution, I think. Here is how it looks in PHP:
//$p is an array of latitude, longitude, value, and distance from the centerpoint
//$cx,$cy are the lat/lon of the center point, $cr is the radius of the circle
//$pdist is the distance from each node to its edge (in this case, .5 km, since it is a 1km x 1km grid)
function sum_circle($p, $cx, $cy, $cr, $pdist) {
$total = 0; //initialize the total
$hyp = sqrt(($pdist*$pdist)+($pdist*$pdist)); //hypotenuse of distance
for($i=0; $i<count($p); $i++) { //cycle over all points
$px = $p[$i][0]; //x value of point
$py = $p[$i][1]; //y value of point
$pv = $p[$i][2]; //associated value of point (e.g. population)
$dist = $p[$i][3]; //calculated distance of point coordinate to centerpoint
//first, the easy case — items that are well outside the maximum distance
if($dist>$cr+$hyp) { //if the distance is greater than circle radius plus the hypoteneuse
$per = 0; //then use 0% of its associated value
} else if($dist+$hyp<=$cr) { //other easy case - completely inside circle (distance + hypotenuse <= radius)
$per = 1; //then use 100% of its associated value
} else { //the edge cases
$mx = ($cx-$px); $my = ($cy-$py); //calculate the angle of the difference
$theta = abs(rad2deg(atan2($my,$mx)));
$theta = abs((($theta + 89) % 90 + 90) % 90 - 89); //reduce it to a positive degree between 0 and 90
$tf = abs(1-($theta/45)); //this basically makes it so that if the angle is close to 45, it returns 0,
//if it is close to 0 or 90, it returns 1
$hyp_adjust = ($hyp*(1-$tf)+($pdist*$tf)); //now we create a mixed value that is weighted by whether the
//hypotenuse or the distance between cells should be used
$per = ($cr-$dist+$hyp_adjust)/100; //lastly, we use the above numbers to estimate what percentage of
//the square associated with the centerpoint is covered
if($per>1) $per = 1; //normalize for over 100% or under 0%
if($per<0) $per = 0;
}
$total+=$per*$pv; //add the value multiplied by the percentage to the total
}
return $total;
}
This seems to work and is pretty fast (even though it does use some trig on the edge cases). The basic logic is that when calculating edge cases, the two extreme possibilities is that the circle radius is either exactly perpendicular to the grid, or exactly at 45 degree angles from it. So it figures out roughly where between those extremes it falls and then uses that to figure out roughly what percentage of the grid square is covered. It gives plausible results in my testing.
For the size of the squares and circles I am using, this seems to be adequate?
I wrote a little application in Processing.js to try and help me work this out. Without explaining all of it, you can see how the algorithm is "thinking" by looking at this screenshot:
Basically, if the circle is yellow it means it has already figured out it is 100% in, and if it is red it is already quickly screened as 100% out. The other cases are the edge cases. The number (ranging from 0 to 1) under the dot is the (rounded) percentage of coverage calculated using the above method, while the number under that is the calculated theta value used in the above code.
For my purposes I think this approximation is workable.
With enough classification (sketched below) all computations can be reduced to a primitive calculation, the one that provides the angular area of the orange region depicted in the image
When y0 > 0, as illustrated above, and regardless of whether x0 is positive or negative, the orange area can be calculated accurately as the integral from x0 to x1 of sqrt(r^2 - y^2) minus the rectangular area (x1 - x0) * (y1 - y0). The integral has a well known closed expression and therefore there is no need to use any numerical algorithm for calculating it.
Other intersections between a circle and a square can be reduced to a combination of rectangles and right-angular shapes as the one painted in orange above. For instance, an intersection delimited by the horizontal and vertical orange rays in the following picture can be expressed by summing the area of the red rectangle plus two angular shapes: the blue and the green.
The blue area results from a direct application of the primitive case identified above (where the inferior rectangle collapses to nothing.) The green one can also be measured in the same way, once the negative y coordinate is replaced by its absolute value (the other y being 0).
Applying these ideas one could enumerate all cases. Basically, one should consider the case where just one, two, three or four corners of the square lie inside the circle, while the remaining (if any) fall outside. The enumeration is a problem in itself, but it can be solved, at least in theory, by considering a relatively small number of "typical" configurations.
For each of the cases enumerated as described a decomposition on some few rectangles and angular areas has to be calculated and the parts added up (or subtracted) as shown in the three-color example above. The area of every part would reduce to rectangular or primitive angular areas.
A considerably amount of work has to be done to turn this line of attack into a working algorithm. A deeper analysis could shed some light on how to minimize the number of "typical" configurations to consider. If not, I think that the amount of combinations to consider, however large, should be manageable.
In case your problem admits an approximate answer there is another technique you could use which is much simpler to program. The whole idea of this problem reduces to calculate the area of the intersection of a square and a circle. I didn't explain this in my other answer, but finding the squares that are likely to intercept the circle shouldn't be a problem, otherwise, let us know.
The idea of calculating the approximate area of the intersection is very simple. Generate enough points in the square at random and check how many of them belong in the circle. The ratio between the number of points in the circle and the total number of random points in the square will give you the proportion of the intersection with respect to the square's area.
Now, given that you have to repeat the same routine for all squares surrounding the circle (i.e., squares which center has a distance to the circle's center not very different from the circle's radius) you could re-use the random points by translating them from one square to the other.
I don't want to go into details if this method is not appropriate for your problem, so let me just indicate that generating random points uniformly distributed in the square is fairly easy. You only need to generate random numbers for the x coordinate and, independently, random numbers for y. Then just consider all pairs (x, y). Then, for every (x, y) verify whether (x - a)^2 + (y - b)^2 <= r^2 or not, where (a, b) stands for the circle's center and r for the radius.
I have a data series with 5 decimals such as 0,58861; now I plot with a XYChart as LineChart but I only see 3 numbers plotted, i.e. 0,58 or .584.
I have also tryed to change font size
yAxis.setTickLabelFont(Font.font("Arial", 5));
with no result, I always have 3 numbers plotted.
Below are two picture to show this behavior.
How to set more decimal on Y axis?
So what is wrong with that y-axis plotted numbers? You can think 0.58 as 0.58000 etc. These are just major ticks and not the points (numbers) of your data series. If you want to see more ticks and hence more precise measure values change the tickUnit parameter:
NumberAxis(double lowerBound, double upperBound, double tickUnit)
But this time if your datas range (upperBound-lowerBound) is large according to tickUnit then your graph's shape and form will degrade. To overcome this problem play with lowerBound and upperBound values to show only part of your data series as like they have been zoomified.
To change the tick label font and size, try:
yAxis.setTickLabelFont(Font.font("Arial", FontWeight.MEDIUM, 18));
Changing the font size will not help. You have to change the tick label formatter using the setTickLabelFormatter function.
Basically, I have a context where I can't programatically tint an image, though I can change it's alpha value. With some experimentation, I've found that I can layer a red, blue, and green version of the image, with specific alpha values, to produce a wide range of colors. However, I am wondering if it's possible to achieve a true RGB representation through this method? If so, what is the formula for converting an RGB value into different alpha values for the red, blue, and green layers.
The basic "equation" of alpha combination is:
alpha * (R1,G1,B1) + (1-alpha) * (R2,G2,B2)
When you have three layers with alpha you are actually combining 4 layers (the 4th one is black) so the final color is:
alpha1 * (R1,G1,B1) + (1-alpha1) * (
alpha2 * (R2,G2,B2) + (1-alpha2) * (
alpha3 * (R3,G3,B3) + (1-alpha2) * (0,0,0) ) )
Provided you have the same image on each layer and layer1 is the red channel (G1=B1=0) and layer2 is green and layer3 is blue you get:
(alpha1 * R, (1-alpha1)*alpha2 * G, (1-alpha1)*(1-alpha2)*alpha3 * B)
For a white pixel you can do any possible color. For a black pixel you cannot do anything but black. For any other pixel, you are restricted by the values of R, G and B.
Say you wanted to achieve (Rd, Gd, Bd) at a pixel where the current color is (R, G, B) then you would have to choose:
alpha1 = Rd/R
alpha2 = Gd/(G*(1-alpha1))
alpha3 = Bd/(B*(1-alpha1)*(1-alpha2))
The problem is that alpha can typically only be between 0 and 1. So, for example, if Rd > R there is nothing you can do.
You can do better if you can control the blending function (for example, in Photoshop).
I don't think that's possible, if I understand you correctly.
If, for a certain pixel, your image's red value is, say, 0.5, you can combine that with an alpha in the (typical) range [0,1] to form any value up to and including 0.5, but you can't go above, to get e.g. 0.6 or so as the output value.
If you're looking to create 3 layers that blended together add up to the original image, it's quite possible. Here's a link to a Python script that calls functions in Paint Shop Pro to do the hard parts.
http://pixelnook.home.comcast.net/~pixelnook/SplitToRGB.htm
If you need more detail than that, leave a comment and I'll try to fill it in later.