What is WebGL color mix calculation algorithm? I need to draw quadrangle with 4-way gradient color fill and I decided to do it with 3-way gradient triangles (like this), calculating the center of quadrangle and using such point for 4 triangles to get the best result of gradient smoothness. To do it right, I need to calculate the color of the center of quadrangle by same way as WebGL calculates color mix for 3-way gradient fill. What is the formular for such calculation?
WebGL uses linear interpolation for vertex attributes. The formula for interpolating a value across a square given samples at the four corners is simply linear interpolation applied twice. In GLSL,
mix(mix(color00, color01, y), mix(color10, color11, y), x)
If you are interested in the center point in particular, this is just
0.25 * (color00 + color01 + color10 + color11)
However, if your goal is to interpolate the four colors smoothly across a square, in a WebGL application, then you don't actually need to perform this calculation yourself, and you don't need to use four triangles!
Create a 2×2 texture with your four colors.
Set its TEXTURE_MAG_FILTER to LINEAR.
Draw your square with that texture applied in the usual fashion, but with texture coordinates ranging from 0.25 to 0.75.
This performs the same interpolation you're looking for, but using built-in facilities. If you wanted, you could also skip using a texture, but still have “texture” coordinates, and use the mix formula above to map the coordinates to your four colors.
The reason this works is that texture coordinates, unlike arbitrary colors, are such that linearly interpolating between 3 points gives you non-degenerate results which you can then use to lookup the color taking into consideration all 4 color values.
Related
The Xiaolin Wu algorithm draws an anti-aliased line between two points. The points can be at sub-pixel, i.e. non-integer coordinates. I'll assume the reader is familiar with the algorithm and just recall the important features. We loop across the major (longer) axis of the line, let's say it's the x-axis, basically proceeding column-by-column. In each column we color two pixels. The computation is equivalent to this: place a 1x1 square centered on the line, at the point whose x coordinate is the center of the the given column of pixels. Let's call it S. If we think of each pixel as a 1x1 square in the plane, we now calculate the area of intersection between S and each of the two pixels it straddles, and use those areas as the intensities with which to color each pixel.
That's nice and clear, but what is going on with the calculations for the endpoints? Because the endpoints can be at non-integer positions, they have to be treated as a special case. Here's the pseudocode from the linked Wikipedia article for handling the first endpoint x0, y0:
// handle first endpoint
xend := round(x0)
yend := y0 + gradient * (xend - x0)
xgap := rfpart(x0 + 0.5)
xpxl1 := xend // this will be used in the main loop
ypxl1 := ipart(yend)
plot(ypxl1, xpxl1, rfpart(yend) * xgap)
plot(ypxl1+1, xpxl1, fpart(yend) * xgap)
I edited out the if (steep) condition, so this is the code for the case when the slope of the line is less than 1. rfpart is 1-fpart, and fpart is the fractional part. ipart is the integer part.
I just have no idea what this calculation is supposed to be doing, and I can't find any explanations online. I can see that yend is the y-coordinate of the line above xend, and xend is the x coordinate of the pixel that the starting point (x0, y0) is inside of. Why are we even bothering to calculate yend? It's as if we're extending the line until the nearest integer x-coordinate.
I realize that we're coloring both the pixel that the endpoint is in, and the pixel either immediately above or below it, using certain intensities. I just don't understand the logic behind where those intensities come from.
With the Xiaolin Wu algorithm (and sub-pixel rendering techniques in general) we imagine that the screen is a continuous geometric plane, and each pixel is a 1x1 square region of that plane. We identify the centers of the pixels as being the points with integer coordinates.
First, we find the so-called "major axis" of the line, the axis along which the line is longest. Let's say that it's the x axis. We now loop across each one-pixel-wide column that the line passes through. For each column, we find the point on the line which is at the center of that column, i.e. such that the x-axis is an integer. We imagine there's a 1x1 square centered at that point. That square will completely fill the width of that column and will overlap two different pixels. We color each of those pixels according to the area of the overlap between the square and the pixel.
For the endpoints, we do things slightly differently: we still draw a square centered at the place where the line crosses the centerline of the column, but we cut that square off in the horizontal direction at the endpoint of the line. This is illustrated below.
This is a zoomed-in view of four pixels. The black crosses represent the centers of those pixels, and the red line is the line we want to draw. The red circle (x0, y0) is the starting point for the line, the line should extend from that point off to the right.
You can see the grey squares centered on the red crosses. Each pixel is going to be colored according to the area of overlap with those squares. However, in the left-hand column, we cut-off the square at x-coordinate x0. In light grey you can see the entire square, but only the part in dark grey is used for the area calculation. There are probably other ways we could have handled the endpoints, for instance we could have shifted the dark grey region up a bit so it's vertically centered at the y-coordinate y0. Presumably it doesn't make much visible difference, and this is computationally efficient.
I've annotated the drawing using the names of variables from the pseudocode on Wikipedia.
The algorithm is approximate at endpoints. This is justified because exact computation would be fairly complex (and depend on the type of endpoint), for a result barely perceivable. What matters is aliasing along the segment.
Given a number of points on a 2d surface and radiuses for these points I can easily paint circles for them. What I need is an algorithm that only paints the envelope (right word for what I am looking for?) or outer bound of these combined circles. Additionally a second set of circles can 'encroach' on these circles, resulting in a kind of 'border'.
Image of what I am looking for
A quick way to draw the outline of the union of the disks is to
fill all disks in yellow, then
fill all disks in white with a smaller radius.
This can be adapted to the "encroached" circles, provided you only fill the remaining portions of the disks. Unfortunately, in a general setting finding the remaining portions can be an uneasy geometric problem.
There is an alternative approach which can work in all cases:
fill an image with zeroes, then for all disks fill every pixel with the value of the distance to the circumference (maximum at the center), but only keep the highest value so far.
while you do this, fill a second image with the color of the disk that achieved that highest value. (Initialize the image with the background color.)
At the end of this process, the first image will represent a "terrain" made of intersecting cones; and for every point of the terrain, you will know the color.
finally, color the pixels that have a height smaller than the desired stroke width, using the color map.
You can do the drawing in two steps.
1) Draw the outline using the following method: For each point, draw a circle using your favorite circle-drawing method, but before drawing a pixel, ensure that it is not contained inside any other circle. Do this for every point and you will get your outline.
2) Draw the borders between different sets using the following method: For each pair of points from different sets, calculate the two intersection points of the circles. If there is an intersection, the border can be drawn as a segment joining these two points. However, you have to make two lines, one for circle A, and another for circle B. To draw the line for circle A, slightly offset the segment towards point A. Then, use your favorite line-drawing method, but before drawing a pixel, ensure that it is closer to point A that any other point of the opposite set. After drawing the line, repeat the process for circle B. Note that both segment are not guaranteed to be the same length since the asymmetry of the points of the different sets. It will, however, always form a closed shape when all outlines and borders are drawn.
I have a 2d grid where pixel centers are at the intersection of two half-grid lines, as shown below.
I also have a shape that is drawn on this grid. In my case the shape is a glyph, and is described by segments. Each segment has a start point, end point and a number of off-curve points. These segments can be quadratic curves or lines. What's important is that I can know the points and functions that make up the outline of the shape.
The rule for deciding which pixels should be turned on is simple: if the center of the pixel falls within the shape outline, turn that pixel on. The following image shows an example of applying this rule.
Now the problem I'm facing has to do with anti aliasing. What I'd like to do is to calculate what percentage of the area of a given pixel falls within the outline. As an example, in the image above, I've drawn a red square around a pixel that would be about 15% inside the shape.
The purpose of this would be so that I can then turn that pixel on only by 15% and thus get some cleaner edges for the final raster image.
While I was able to find algorithms for determining if a given point falls within a polygon (ray casting), I wasn't able to find anything about this type of problem.
Can someone can point me toward some algorithms to achieve this? Also let me know if I'm going about this problem in the wrong way!
This sounds like an X, Y problem.
You are asking for a way to calculate the perecentage of pixel coverage, but based on your question, it sounds that what you want to do is anti alias a polygon.
If you are working only with single color 2D shapes (i.e red, blue, magenta... squares, lines, curves...) A very simple solution is to create your image and blur the result afterwards.
This will automatically give you a smooth outline and is simple to implement in many languages.
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 an image with some curve draw in it and I want to extrapolate positions of next few pixels based on already drawn ones. An example is shown in figure 1. For this situation it is easy to fit curve (some parabola) using the least square fit (figure 2) and then based on this fit rasterize the curve to find next pixels (I also need the vector curve for some further calculations).
The problem is that there is often situations like one shown in figure 3, where I can't use curves like parabola, because I can't define such function. Have you any idea how to extrapolate curve/pixels which will work in both cases?