This question is a little bit odd. I have to make sure of the distance between letters above and below. Now when calculating a letter height in Pixel, say font size = 14px does this mean my alloted pixel height for a letter is 14 pixels? What about the letters with tail? How are their tails alloted in Pixels?
------------
| ** |
| * * |
| ****** | = for example this is a 14px font size
| * * |
|* *|
------------
What about my lower case letters with tail
------------
| |
| ****** |
| * * | = this letter q for example
| * * |
| ****** |
--------*---
*
Is there a specific height for its tail that overflows the alloted pixel for a font?
the tail is included in the allotted pixels if I remember correctly. Check this with adding a border to a span with just a letter:
<span style="border: 1px solid #f00">q</span>
I would imagine that it depends largely on the system you are using to measure the height of the glyphs. If you're lucky, the font itself provides metrics for the height of a line of text. When height metrics are not available, generally speaking (and particularly with web technologies) the height is made consistent with that of twice the height of a lowercase "x" (the height of the lowercase "x" is known as the x-height). There's a section in the CSS specification on how the x-height of a font can be estimated that has more information.
Related
After stripping off header bytes and de-compressing the pixel values, a PNG file leaves us with a set of rows (a horizontal strip of the image one pixel high).
Each row starts with a single byte specifying the filter used, followed by RGB values:
+-----+-----+-----+-----+-----+-----+-----+
| 0:F | 1:R | 2:G | 3:B | 4:R | 5:G | 6:B | // end of first row in image
+-----+-----+-----+-----+-----+-----+-----+
| 7:F | 8:R | 9:G |10:B |11:R |12:G |13:B | // end of second row
+-----+-----+-----+-----+-----+-----+-----+
In an image without the filter byte, I could just divide the index by 3 (since there are three values per RGB pixel), then use these formulas to get the x/y position of that pixel:
x = index % width
y = index / width
But the filter byte is throwing me off! How do I get the x/y position of a pixel, given a red pixel's byte index? (Say at byte 4 or at byte 11, as shown above.)
I've tried all kinds of permutations but I think there must be an elegant solution!
Based on comments from #usr2564301, I think this works correctly:
y = ((index-1) / 3) / width
x = ((index-y) / 3) % width
Where width is the width of the image in pixels, not the width of the row of bytes.
We subtract y from the index because each row has a single filter byte and we need to remove them all to get the x position.
Alternatively, y can be calculated using:
y = index / row_width
Where row_width is the number of bytes per row: three for RGB and one filter byte times the width of the image.
I need to find an algorithm to find the least number of overlapping rectangles within a given rectangle R that do not intersect with the union of a set of other rectangles contained within R. These inner rectangles can overlap. Here's a terrible ASCII drawing of an example R:
A-----------------B-------------------------+
| |
| |
| |
| |
| +--------+ |
| |........| |
| |........| |
C +---D........| |
| |.........+--+ |
| |.........| |
| ++........+------+ |
| |...............| |
G +---H...........| |
| |...........| |
| |...........| |
| |...........| |
| +-----------+ |
| |
| |
| |
E-------------I----F------------------------+
The rectangles here would include (A, D), (A, I), (G, F). This seems like a problem for which the solution is well-understood, but for which I simply lack the vocabulary. Any answers, pointers, RTFMs cheerfully and gratefully accepted. Thanks!
EDIT: As per #Paul's observation below, what I'm trying to do is find a set of rectangles that cover the space in R without covering any of polygon comprised of the union of the inner set. If that makes sense.
I believe this is one possible way to solve.
I will refer to the overlapping rectangles as "white", and the ones in the solution as "black"
First of all, let's assume we have a data structure suitable for search on intersection. One possible data structure is an Interval Tree, using points on one of the coordinates as intervals (for example, if a rectangle is defined by two points (x0,y0) and (x1, y1), use (x0, y1) as interval. The link also explain how to extend to higher dimensions (in your case you need 2).
I won't go in the detail of an implementation of such data structure, but let's assume we have one called Rectangles, with the following API defined:
void add(Rectangle r)
void remove(Rectangle r)
Rectangle[] getIntersecting(Rectangle r)
Rectangle[] getAdjacent(Rectangle r)
Ok, now create two instances of Rectangles called black and white. Initialize white with all the white rectangles. Initializie black with the R rectangle (the whole domain).
For each rectangle rw in white get the array arr of intersecting rectangles from black.
For each rectangle rb in black, determine the result of rw-rb. This is a set set of 0, 1, 2, 3 or 4 rectangles, depending on how the two rectangles intersect.
remove rw from white, and add the content of set to it. This may require merging rectangles from set with rectangle already in white, if such rectangles together form a larger rectangle (they're adjacent sharing one side)
remove rb from black
repeat from 1 until there are no more rectangles in black
Using some basic math, we could say the solution to your problem would be the decomposition of the rectilinear polygon R \ union(rs), where union(rs) represents the polygon inside R. Calculating R \ union(rs) can be done using the Greiner-Hormann-algorithm. Note that this step will result in a polygon with holes and - only if the inner polygon contains holes - multiple other polygons. The decomposition is described here (this is only an approximation, but i wasn't able to find a precise algorithm so far).
Imagine a volumetric cube of N³ resolution that is filled with occluding voxels. The cube could be completely filled, or contain curvy "tunnels", or walls - or just a few stray voxels; We now pick any two of the six faces of the bounding cube and attempt to find a line that connects those two faces without hitting any voxel inside it. If such a line exists, the faces can see each other, otherwise, they're completely occluded.
My question is: does an O(n) (or better) algorithm exist to quickly discern if such a line can be drawn? The exact parameters of the line do not matter.
I'm somewhat unclear on the exact parameters of being a straight line in this (continuous? discrete?) space, but I wonder if you're looking for a dynamic programming solution?
Perhaps lets restrict to 2-D left to right case to build the algorithm and then generalize:
Loop over first column of the array,
for each opaque square, mark that it is impossible to build a ray which reaches this square
for each non opaque square, mark that it is possible to reach this square -AND- track ranges of slopes can reach this square. You may restrict the set of slopes in this initialization by the set of slopes that could potentially reach the opposite end of your voxel volume.
Then loop over the next column
Each square is potentially able to be reached by any square in the previous column, but only if the range of slopes that can reach the square in the previous column intersects the range of slopes necessary to reach the current square from the square in the previous column.
You thus set the valid range of slopes in the current square to the union of the intersections of the valid ranges from previous squares with valid ranges to current square.
You continue looping over columns until you hit the far end, and any reachable entries on the far end will report the ranges of slopes of vectors that allow hitting that square.
The speed of the algorithm is heavily dependent on how quickly you can union and intersect ranges of slopes (or in the 3D case, arbitrary ranges of UV coordinates). In 2D continuous space this operation can be done quickly by sorting, in a 3D discrete space, you can use a set of possible vector slopes in X,Y dependent on dimensions of your voxel space. In a 3D continuous space, some type of quadtree would probably approach what can be achieved by sorting in 2D.
The algorithm loops once over each cell in your input (Do you consider this O(n) or O(n^3)?), and takes time that will be bounded by the union of intersections call times the number of elements in your space (Worst case O(n^2) in discrete case I believe, but will shrink dramatically in the initialization step if the opposite end of the volume is far away, and may shrink quickly in the case of many opaque cells and proper data structures)
As far as I can tell, processing order of slices of the volume doesn't actually matter, so if you know that certain spots are very opaque (by sum of opaque cells or whatever), you might use a heuristic to reorder intersection operations.
A Voxel cube would look like a Rubik Cube, voxel structure is a 3D matrix of blocks, so to draw a line from one side to the other, we need to draw within each related block the line that connects to the next, together the lines form one continuous line through the cube.
The following algorithm works fine if implemented well, since you're going to work on local coordinates within the cube, any transformations of the cube itself will be applied automatically by the 3D engine when it translate it into world coordinates.
Time Complexity
MATRIX.MAX_Z * (
Time(MATRIX.GET_VOXEL(x,y,z))
+ Time(VOXEL.DRAW-LINE(0,0,0, 0,0,VOXEL_DEPTH))
)
Algorithm
FUNCTION DRAW (INTEGER X, INTEGER Y)
INTEGER VOXEL_X = X / MATRIX.VOXEL_WIDTH
INTEGER VOXEL_Y = Y / MATRIX.VOXEL_HEIGHT
FOR i = 0 .. (MATRIX.MAX_Z-1)
VOXEL V = MATRIX.GET_VOXEL(VOXEL_X, VOXEL_Y, i)
INTEGER X_0 = X % MATRIX.VOXEL_WIDTH
INTEGER Y_0 = Y % MATRIX.VOXEL_HEIGHT
INTEGER Z_0 = 0
INTEGER X_1 = X_0
INTEGER Y_1 = Y_0
INTEGER Z_1 = (MATRIX.VOXEL_DEPTH-1)
V.DRAW-LINE(X_0,Y_0,Z_0, X_1,Y_1,Z_1)
END-FOR
END-FUNCTION
So one easy way to do this test is to render the view (orthographic) from the source to the target cube at arbitrary resolution. If there is any background pixel left, there exists a line between the two rectangles. So the complexity comes down to two things:
The resolution at which you render
How fast can you render an orthographic, binary view
Now for that binary rendering the only thing you need to know is covered/not covered. That comes down to two octrees, one for minimum and one for maximum. The minimum tree tracks "is there any open child node (or)" the maximum tracks "is there any closed child node (and)". Building those trees is n log(n), but the query is only log(n).
For the target resolution, m, it should be only log(m). Even if you go up to m=2^23 for float size.
Breaking the problem down to two dimensions, it is clear that some voxel configurations are obviously impenetrable from, say, left to right:
+-+-+-+ +-+-+-+-+-+
| |#| | |#| | | | |
+-+-+-+ +-+-+-+-+-+
| |#| | |#| | |#| |
+-+-+-+ +-+-+-+-+-+
| |#| | |#| | |#| |
+-+-+-+ +-+-+-+-+-+
|#| | |#| |
+-+-+-+-+-+
| | | |#| |
+-+-+-+-+-+
... but this might not be impenetrable, depending on how you handle your corners:
+-+-+-+-+-+
|#| | | |/|
+-+-+-+-+-+
|#| | |/| |
+-+-+-+-+-+
|#| |/|#| |
+-+-+-+-+-+
|#|/| |#| |
+-+-+-+-+-+
|/| | |#| |
+-+-+-+-+-+
... and this is definitely possible:
+-+-+-+-+-+
|#| | | | |
+-+-+-+-+-+
|#| | | | |
+-+-+-+-+-+
|#| | | | |
+-+-+-+-+-+
| | | |#| |
+-+-+-+-+-+
| | | |#| |
+-+-+-+-+-+
Now, if you can think of any trick that can tell the upper 2D-cubes from the lower one, that might eliminate at least some impossible pixel/voxel configurations -- but I'm afraid you need to test every pixel on your target side for light coming through from your source side from any angle, which sounds awfully like an n-squared problem (2D), or n^4 in 3D.
In 2D, I'd start at the top of the left side and check if the line connecting my voxel centre to the top right hits an occluding pixel: if not, we're done; if it does, you advance your angle so that the ray passes the lower left corner of the occlusion and continue checking until you either find a passage or get to the end of the right side.
Continue with every pixel on your source side, until you are done -- one way or the other.
But that's brute-force, and I'd be interested to see a more elegant solution, perhaps by G. Bach ...?
I have a set of rectangles of different size. Each rectangle has an anchor point on the 2 dimensional plane where the center of the rectangle should be placed. The rectangles should not overlap and the center of a rectangle should be as close as possible to its anchor point. So if the center of the rectangle_i is vector c_i and its anchor point is vector a_i then the target function would be min(sum_i((c_i - a_i)^2)). I am looking for an algorithm that approaches the optimal solution as much as possible in O(n).
The rectangles can not be rotated.
The inputs of the problem are:
the size of n rectangle
for each rectangle the coordinates of the associated anchor point.
The output should be the position of the rectangles i.e. coordinates of the center of each rectangle.
In the example below x signs the center of the rectangle and o the anchor points:
+-----------+
| |
+-----------+| x |
| || o |
| x |+-----------+
| o | +-------------+
+-----------+ | o |
+---------+| x |
| o || |
| x |+-------------+
| |
+---------+
I'm trying to implement an animation of a ball bouncing between 4 perpendicular walls, being the speed of the ball constant. The problem is, the framework I'm using requires me to tell the origin and the destination of the ball each time it collides with a wall.
In the moment of the collision, I have access to both the ball's current and previous positions of contact with the walls. Given the coordinates x_min, x_max, y_min and y_max of the walls, and these two positions of the ball, what is the simplest way to calculate its next position?
All the algorithms I thought about followed kind of a brute force approach, with many if-else statements... I wonder if there is some elegant way of handling this.
[sorry, this is incomplete - i would have posted it as a comment, but it's too large and involves ascii art. i may delete it later.]
if you want a compact, elegant approach it's probably easier to think of the ball as continuing in a straight line, crossing over a repeated pattern of rectangles.
+------+------+--*---+
| | | * |
| | |* |
+------+------*------+
| | *| |
| | * | |
+------+---*--+------+
| | * | |
| | * | |
+------+*-----+------+
| * | |
| *| | |
+----*-+------+------+
| * | | |
| * | | |
+-*----+------+------+
(you need to reflect the rectangles, but then get the bounce "for free").
and i am pretty sure that you could then use something similar to bresenham's algorithm
to calculate the points of intersection.
[thanks for the vote, but i have to say i think this could be a world of pain to get right. tracking reflections, particularly if exactly hit a corner, is going to be tricky... sometimes it's easier to live with ugly code!]
Let's say the previous bounce was off the left wall at position (x_min, y_prev) and the current bounce is off the top wall at (x_curr, y_max). The next bounce should be off the right wall at (x_max, y_next) where:
y_next = y_max - (y_max - y_prev) * (x_max - x_curr) / (x_curr - x_min)
It's simple geometry that the triangle defined by (previous bounce, top left corner, current bounce) is similar (same shape but different size) to the triangle (current bounce, top right corner, next bounce). Like this:
+--*----+
| / \ |
|/ \ |
* \ |
| \|
| *
| |
+-------+
If y_next is less than y_min, that means the ball will hit the bottom wall before the right wall. The will happen at (x_next, y_min) where:
x_next = x_curr + (x_curr - x_min) * (y_max - y_min) / (y_max - y_prev)
Something like this:
+--*------+
| / \ |
|/ \ |
* \ |
| \ |
+-------*-+
I'm not sure whether this is similar to what you have in mind, but my idea is to basically calculate the position as if there's no wall, and then flip the applicable coordinate using the wall as the centre point.
So, first you calculate:
new
\
\
\
---------
\
\
old
Then you translate it to:
---------
/ \
/ \
/ old
new
Pseudo-code:
newX = oldX + xInc
newY = oldY + yInc
if newX < 0
newX = -newX
if newY < 0
newY = -newY
if newX > maxX
newX = maxX - (newX - maxX)
// or 2*maxX - newX
if newY > maxY
newY = maxY - (newY - maxY)
// or 2*maxY - newY