I need an algorithm which can parse a 2D array and return the largest continuous rectangle. For reference, look at the image I made demonstrating my question.
Generally you solve these sorts of problems using what are called scan line algorithms. They examine the data one row (or scan line) at a time building up the answer you are looking for, in your case candidate rectangles.
Here's a rough outline of how it would work.
Number all the rows in your image from 0..6, I'll work from the bottom up.
Examining row 0 you have the beginnings of two rectangles (I am assuming you are only interested in the black square). I'll refer to rectangles using (x, y, width, height). The two active rectangles are (1,0,2,1) and (4,0,6,1). You add these to a list of active rectangles. This list is sorted by increasing x coordinate.
You are now done with scan line 0, so you increment your scan line.
Examining row 1 you work along the row seeing if you have any of the following:
new active rectangles
space for existing rectangles to grow
obstacles which split existing rectangles
obstacles which require you to remove a rectangle from the active list
As you work along the row you will see that you have a new active rect (0,1,8,1), we can grow one of existing active ones to (1,0,2,2) and we need to remove the active (4,0,6,1) replacing it with two narrower ones. We need to remember this one. It is the largest we have seen to far. It is replaced with two new active ones: (4,0,4,2) and (9,0,1,2)
So at the send of scan line 1 we have:
Active List: (0,1,8,1), (1,0,2,2), (4,0,4,2), (9, 0, 1, 2)
Biggest so far: (4,0,6,1)
You continue in this manner until you run out of scan lines.
The tricky part is coding up the routine that runs along the scan line updating the active list. If you do it correctly you will consider each pixel only once.
Hope this helps. It is a little tricky to describe.
I like a region growing approach for this.
For each open point in ARRAY
grow EAST as far as possible
grow WEST as far as possible
grow NORTH as far as possible by adding rows
grow SOUTH as far as possible by adding rows
save the resulting area for the seed pixel used
After looping through each point in ARRAY, pick the seed pixel with the largest area result
...would be a thorough, but maybe not-the-most-efficient way to go about it.
I suppose you need to answer the philosophical question "Is a line of points a skinny rectangle?" If a line == a thin rectangle, you could optimize further by:
Create a second array of integers called LINES that has the same dimensions as ARRAY
Loop through each point in ARRAY
Determine the longest valid line to the EAST that begins at each point and save its length in the corresponding cell of LINES.
After doing this for each point in ARRAY, loop through LINES
For each point in LINES, determine how many neighbors SOUTH have the same length value or less.
Accept a SOUTHERN neighbor with a smaller length if doing so will increase the area of the rectangle.
The largest rectangle using that seed point is (Number_of_acceptable_southern_neighbors*the_length_of_longest_accepted_line)
As the largest rectangular area for each seed is calculated, check to see if you have a new max value and save the result if you do.
And... you could do this without allocating an array LINES, but I thought using it in my explanation made the description simpler.
And... I think you need to do this same sort of thing with VERTICAL_LINES and EASTERN_NEIGHBORS, or some cases might miss big rectangles that are tall and skinny. So maybe this second algorithm isn't so optimized after all.
Use the first method to check your work. I think Knuth said "...premature optimization is the root of all evil."
HTH,
Perry
ADDENDUM:Several edits later, I think this answer deserves a group upvote.
A straight forward approach would be to do a loop through all the potential rectangles in the grid, figure out their area, and if it is greater than the current highest area, select it as the highest:
var biggestFound
for each potential rectangle:
if area(this potential rectangle) > area(biggestFound)
biggestFound = this potential rectangle
Then you simply need to find the potential rectangles.
for each square in grid:
recursive loop 1:
if not occupied:
grow right until occupied, and return a rectangle
grow down one and recurse (call loop 1)
This will duplicate a lot of work (for example you will re-evaluate a lot of sub-rectangles), but it should give you an answer.
Edit
An alternate approach might be to start with a single square the size of the grid, and "subtract" occupied squares to end up with a final set of potential rectangles. There might be optimization opportunities here using quadtrees, and in ensuring that you keep split rectangles "in order", top to bottom, left to right, in case you need to re-combine rectangles farther down in the algorithm.
If you are actually starting out with rectangular data (for your "populated grid" set), instead of a loose pixel grid, then you could easily get better perf out of a rectangle/region subtracting algorithm.
I'm not going to post pseudo-code for this because the idea is completely experimental, and I have no idea if the perf will be any better for a loose pixel grid ;)
Windows system "regions" and "dirty rectangles", as well as general "temporal caching" might be good inspiration here for more efficiency. There are also a lot of z-buffer tricks if this is for a graphics algorithm...
Use dynamic programming approach. Consider a function S(x,y) such that S(x,y) holds the area of the largest rectangle where (x,y) are the lowest-right-most corner cell of the rectangle; x is the row co-ordinate and y is the column co-ordinate of the rectangle.
For example, in your figure, S(1,1) = 1, S(1,2)=2, S(2,1)=2, and S(2,2) = 4. But, S(3,1)=0, because this cell is filled. S(8,5)=40, which says that the largest rectangle for which the lowest-right cell is (8,5) has the area 40, which happens to be the optimum solution in this example.
You can easily write a dynamic programming equation of S(x,y) from the value of S(x-1,y), S(x,y-1) and S(x-1,y-1). Using that you can obtain the values of all S(x,y) in O(mn) time, where m and n are the row and column dimension of the given table. Once, S(x,y) are know for all 1<=x <= m, and for all 1 <= y <= n, we simply need to find the x, and y for which S(x,y) is the largest; this step also takes O(mn) time. By keeping addition data, you can also find the side-length of the largest rectangle.
The overall complexity is O(mn). To understand more on this, Read Chapter 15 or Cormen's algorithm book, specifically Section 15.4.
Related
Well, OpenCv comes with its function findCheckerboardCorners() in C++ which goes like
bool findChessboardCorners(InputArray image, Size patternSize,
OutputArray corners,
int flags=CALIB_CB_ADAPTIVE_THRESH+CALIB_CB_NORMALIZE_IMAGE )
After using this function for a while, one thing that i understood was that the pattern size must comply with the image to a very good extent, else the algorithm refuses to detect any Chessboard altogether. I was wondering if there were any random image of a chessboard, this function would fail as it is impractical to enter the precise values of the patternSize. Is there a way, the patternSize for this function could be obtained from the image provided. Any help would be appreciated. Thanks.
Short answer: you cannot.
The OpenCV checkerboard detection code assumes that the pattern is uniform (all squares have the same size) and therefore, in order to uniquely locate its position in the image, the following two conditions must be true:
The pattern is entirely visible.
The pattern has a known numbers of rows and columns.
If either 1 or 2 is violated there is no way to know which corner is, say, the "top left" one.
For a more general case, and in particular if you anticipate that the pattern may be partially occluded, you must use a different algorithm and a non-uniform pattern, upon which corners can be uniquely identified.
There are various way to do that. My favorite pattern is Matsunaga and Kanatani's "2D barcode" one, which uses sequences of square lengths with unique crossratios. See the paper here. In order to match it, once you have sorted the corners into a grid, you can use a simple majority voting algorithm:
Precompute the crossratios of all the pattern's consecutive 4-tuples of corners, in both the horizontal and vertical directions.
Do the above for the detected corners in the grid.
For every possible horizontal shift
Over every row
Accumulate the number of crossratios that agree within a threshold
Select the horizontal shift with the highest number of agreements.
Repeat the above for every possible vertical shift, counting crossratios along the columns.
Repeat the above two steps reversing the order of the crossratios in the vertical and horizontal and vertical direction, separately and jointly, to account for reflections and rotations.
Placing the detected corners in a grid can be achieved in various ways. There is an often-rediscovered algorithm that uses topological proximity. The idea is to first associate each corner to all the squares within a small window of it, thus building a corner->squares table, and then traverse it as a graph to build a global table of the offsets of each corner from one another.
The doc for findChessboardCorners says that
patternSize – Number of inner corners per a chessboard row and
column
So patternSize is not the size of the chessboard inside the image but the number of inner corners. The number of inner corners does not depend from the size of the chessboard inside the image.
For example for the following image https://github.com/Itseez/opencv/blob/3.1.0/samples/data/chessboard.png
patternSize should be cv::Size(7,7).
I'm trying to fit a rectangle around a set of 8 2D-Points, while trying to minimize the covered area.
Example:
The rectangle may be scaled and rotated. However it needs to stay a rectangle.
My first approach was to brute force each possible rotation, fit the rectangle as close as possible, and calculate the covered area. The best fit would be then the rotation with the lowest area.
However this does not really sound like the best solution.
Is there any better way for doing this?
I don't know what you mean by "try every possible rotation", as there are infinitely many of them, but this basic idea actually yields a very efficient solution:
The first step is to compute the convex hull. How much this actually saves depends on the distribution of your data, but for points picked uniformly from a unit disk, the number of points on the hull is expected to be O(n^1/3). There are a number of ways to do that:
If the points are already sorted by one of their coordinates, the Graham scan algorithm does that in O(n). For every point in the given order, connect it to the previous two in the hull and then remove every concave point (the only candidate are those neighboring the new point) on the new hull.
If the points are not sorted, the gift-wrapping algorithm is a simple algorithm that runs at O(n*h). For each point on the hull starting from the leftmost point of the input, check every point to see if it's the next point on the hull. h is the number of points on the hull.
Chen's algorithm promises O(n log h) performance, but I haven't quite explored how it works.
another simle idea would be to sort the points by their azimuth and then remove the concave ones. However, this only seems like O(n+sort) at first, but I'm afraid it actually isn't.
At this point, checking every angle collected thus far should suffice (as conjenctured by both me and Oliver Charlesworth, and for which Evgeny Kluev offered a gist of a proof). Finally, let me refer to the relevant reference in Lior Kogan's answer.
For each direction, the bounding box is defined by the same four (not necessarily distinct) points for every angle in that interval. For the candidate directions, you will have at least one arbitrary choice to make. Finding these points might seem like an O(h^2) task until you realise that the extremes for the axis-aligned bounding box are the same extremes that you start the merge from, and that consecutive intervals have their extreme points either identical or consecutive. Let us call the extreme points A,B,C,D in the clockwise order, and let the corresponding lines delimiting the bounding box be a,b,c,d.
So, let's do the math. The bounding box area is given by |a,c| * |b,d|. But |a,c| is just the vector (AC) projected onto the rectangle's direction. Let u be a vector parallel to a and c and let v be the perpendicular vector. Let them vary smoothly across the range. In the vector parlance, the area becomes ((AC).v) / |v| * ((BD).u) / |u| = {((AC).v) ((BD).u)} / {|u| |v|}. Let us also choose that u = (1,y). Then v = (y, -1). If u is vertical, this poses a slight problem involving limits and infinities, so let's just choose u to be horizontal in that case instead. For numerical stability, let's just rotate 90° every u that is outside (1,-1)..(1,1). Translating the area to the cartesian form, if desired, is left as an exercise for the reader.
It has been shown that the minimum area rectangle of a set of points is collinear with one of the edges of the collection's convex hull polygon ["Determining the Minimum-Area Encasing Rectangle for an Arbitrary Closed Curve" [Freeman, Shapira 1975]
An O(nlogn) solution for this problem was published in "On the computation of minimum encasing rectangles and set diameters" [Allison, Noga, 1981]
A simple and elegant O(n) solution was published in "A Linear time algorithm for the minimum area rectangle enclosing a convex polygon" [Arnon, Gieselmann 1983] when the input is the convex hull (The complexity of constructing a convex hull is equal to the complexity of sorting the input points). The solution is based on the Rotating calipers method described in Shamos, 1978. An online demonstration is available here.
They first thing that came to mind when I saw this problem was to use principal component analysis. I conjecture that the smallest rectangle is the one that satisfies two conditions: that the edges are parallel with the principal axes and that at least four points lie on the edges (bounded points). There should be an extension to n dimensions.
I am trying to explore an environment by modelling it with 2 dimensional matrix. However, I don't know the size of the matrix beforehand.
Currently, I am using std::vector< std::vector > structure to abstract the matrix and resize it to certain size. If my application reaches the limit of my original resize, I do that operation again.
I am exploring this matrix with a combination of DFS and A* algorithms. My explorer agent can move forward, backward, left and right. Every time the explorer reaches a position, he adds the neighbors to the stack of DFS. For example, if he is at position (25, 25), it will add the neighbors (25,24), (25, 26), (24, 25) and (26, 25).
So far, it has worked properly. However, there is a scenario that I did not thought. I was always testing my algorithm with the explorer beginning at a corner of the matrix, which behaves great. But, if the explorer starts at the middle of the room or any other position that is not in a corner, my algorithm does not work properly.
That happens because I start my explorer at position 0,0 in the matrix. Therefore, if the explorer begins at the middle of the room, some positions would not be explored, because they would generate negative index for my explorer. Does anyone has any idea of what I can do in order to solve this ?
One way is to simplify it like you said and force it to start from a corner.
The more complicated way would be to, whenever you encounter an index that WOULD be negative, resize the array and all indexes previously generated to force them positive. For performance, probably in large chunks, like simply adding 10 or 100 to everything.
So you add a check for negative numbers when you go to add neighbors and if any of them are negative you apply the same addition to all indexes you've generated so far to force every index positive.
It's just an imaginary coordinate system, the important part is their relative positions. At the end, decide which one should be 0,0 and subtract enough from x,y from it and ALL indexes to normalize the vector back.
Also a performance concern, if you start from a large enough positive number, you may be able to reduce or eliminate the need for this coordinate map shifting until the very end. Like if you start from 100,100 then you would need to travel 100 nodes before you got negative. If there were less than 100 nodes in any direction, you wouldn't have to translate until you've completed mapping.
I do have 4 lists of the x and y coordinates of calibration points. Those are in no particular order and not alligned on any axis (they come from a real calibration picture with slight rotation and distortion) but the lists have the same indexing and cannot be sorted in such a way that each list is ascending/descending. They also hold no integer values but floating point. I am now trying to find the four neighbouring points for a given point.
E.g. searching for the neighbours of the point [150,150] would return [140,140], [140,160], [160,140], [160,160] (except for them actually beeing more like [139.581239,138.28812]).
At the moment I have to look through all calibration points for each point to check. There are about 500 calibration points.
Later during the process, I need to know the 4 neighbours for a random point within the 1600x1400 grid for multiple million times. So it is crucial to find those points as fast as possible to avoid calculation time of days or even weeks.
My first approach was checking each of the ~500 calibration points for each point to check and look at their relative position to the checking point (x_calib > x and y_calib > y would be somewhere in the top, right region of the point) and calculate their distance to it. The closest point in each region (top left, top right, lower left, lower right) would then be the respective neighbour point. That seems not the be efficient at all and takes a lot of time.
The second approach was creating a rainbow table for each of the 1600x1400 points and save the respective neighbours (to be exact, to save the index in the list of coordinates). Later on, the process would check this rainbow table at position [x,y,0], [x,y,1], [x,y,2] and [x,y,3] to get the 4 indices of the 4 neighbour points. Though calculating the rainbow table takes some time (~20 minutes for those ~2 million points), this approach speeds up the later processing. Unfortunatelly, this approach makes it difficult to debug the later steps of the process because it takes this much time before the rest even starts..
I still think there should be room for optimization and I would appreciate any suggestion or help to speed up the whole thing. I allready read about the kd-tree thing but did not quite see the possibility to use it here. I'm hoping that there's an approach for this kind of unsorted (and unsortable) list of points which is more efficient than the rainbow table - or which is at least faster at creating the table.
Thanks in advance!
This question already has answers here:
Rectangles Covering
(12 answers)
Closed 5 years ago.
All values here are real numbers with up to two floating point digits.
Suppose we have a rectangular area, 100.0 by 75.0.
Then you are given a set of rectangles. How can I check whether these rectangles, united, cover the entire area?
If we have
(0,0,50,75)
clearly this does not happen since it only covers half the area. If we have
(0,0,50,75)
(50,0,50,75)
Then this does work, since both rectangles will effectively cover the whole (100,75).
What have I tried
I attempted (didn't work) to make a multi-dimensional array of booleans:
bool area[10000][7500];
These are the dimensions of the area, multiplied by 100 so that I don't have to deal with the floating points. Then I just iterate each of my rectangles (their values also multiplied by 100), and for each "pixel" in them, I turn the boolean to true.
Ultimately, I check if all booleans in the area are true.
This proved to be very dumb. Can you help me find a better way to do this?
I think a strategy like this will work:
Throw away any rectangles that are completely outside your area
Split your area in smaller rectangles along the edges of the rectangles in the list relative to one axis
Split the list of area rectangles created in step 2 along the edges of the rectangles in the cover list relative to the other axis
You now have two lists of rectangles where there must be one in the cover list that covers each of the area rectangles completely
I believe your "bitmap" attempt failed because of the (usual) floating point rounding problems. Unfortunately there's little you can do about it.
Now for the algorithm proper, I would approach it using a subtraction technique.
Let's call your initial set of rectangles R.
Initialize a second set of rectangles S that initially contains a single rectangle covering the whole area.
For each rectangle in R:
For each rectangle in S:
If the two R and S rectangles intersect, replace the S rectangle with as many rectangles as needed (0 to 4 if I'm not mistaken) that cover the non-intersecting part left from the S rectangle.
Continue iterating over S, taking care not to compute anything for the new S rectangles you just added (which we already know don't intersect with the current R rectangle).
Continue iterating over R, this time taking the new S rectangles into account, until either:
There is no rectangle left in S, in which case your R rectangles do cover the whole area.
Or, you iterated over all R rectangles and there are still S rectangles left, in which case your R rectangles don't cover the whole area.
As for the complexity, I'm not sure how it compares to #500-Internal-Server-Error or #Tommy's solutions but hey, at least I managed to come up with something, which I didn't think I could when I read your question at first -- I'm usually not very good at spatial stuff. :)
A conceptually very similar approach to 500 - Internal Server Error's that avoids the O(n^2) search implied by the final step is:
build a list of the vertical boundaries of every rectangle from the covering set;
supposing that makes n boundaries, you've got n+1 vertical strips to consider on the source rectangle;
for each strip, get the list of all rectangles that overlap it (you can do this in O(n) time by pushing from the rectangles to the bins rather than searching backwards);
sort the lists from left to right (ie, O(n log n));
go through the sorted list and try to find a gap where one span ends and nothing else begins until a little later (another O(n) task).
If you find a suitable gap then the original isn't covered. If you don't then it is. And this is essentially how span buffering works, by the way.