How to set a fixed range to the KDChart BarDiagram? - c++

I want to display a BarDiagram using the KDChart library. The vertical values shall be between -120 to 0.
Normally, KDChart starts the bars at 0 as the follow png shows:
Bar Diagram with 0 on top and -120 at the bottom, with the bars growing from 0 towards -120 http://bvdpi.img36.wal8.com/img36/371522_20130905114637/137835282162.png
Now KDChart::CartesianCoordinatePlane has a method setVerticalRangeReversed(bool).
After calling the method, the diagram looks like this:
Bar Diagram with -120 on top and 0 at the bottom, with the bars growing from 0 towards -120 http://bvdpi.img36.wal8.com/img36/371522_20130905114637/137835282217.png
What I need is a mix of both, where the bars are like in the bottom picture, but the Y Axis is like in the upper picture.
Is there any way in KDChart to let the bars start at -120 and grow towards 0?

Because the y axis values has min value -120, I convert the values from [-120,0] to [0, 120],
by each value plus abs(-120).
value += abs(-120);
Also we must convert the y axis ticks, CartesianAxis has a interface setAnnotations(QMap). So I made a map like this:
QMap<double, QString> m;
m.insert(0, "-120");
m.insert(20, "-100");
m.insert(60, "-60");
//...
m.insert(120, "0");
yAxis->setAnnotations(m);
Now, the chart looks normally:

You can set the range of the axis manually using:
CartesianCoordinatePlane::setVerticalRange(const QPair< qreal, qreal > & range)
So your code would look like this:
static_cast<CartesianCoordinatePlane*>(chart->coordinatePlane())->setVerticalRange(qMakePair(-120,0));

Related

QwtPlotBarChart - how to get labels to match midpoint of bars

I am using QwtPlotBarChart to draw a histogram. I have set the chart up so that there is zero spacing between bars, and my xBottom axis has the real range of the data.
Samples are set on the chart using a QVector of QPointF, with the x values corresponding to the midpoints of the bins.
A QwtPlotPicker hovering over the bars shows that they start and end at the actual start and ends of the bins.
However, I am having trouble getting the ticks where the labels are drawn to show up in the correct place along the x axis. I am using a custom scaledraw, similar to the distrowatch example. I have an additional couple of parameters, namely the minimum value of the data range, and the bin size. My label index code looks like this:
virtual QwtText label( double value ) const
{
QwtText lbl;
//const int index = qRound( value );
const int index = (int)(value-_min_val)/_bin_size;
if ( index >= 0 && index < d_labels.size() )
{
lbl = d_labels[ index ];
}
return lbl;
}
This seems to be ok; my labels show the min and max values of each bin and a nearly in the right place.
I have tried to set the tick positions as follows:
QwtScaleDiv div = _plot->axisScaleDiv(QwtPlot::xBottom);
div.setTicks(QwtScaleDiv::MajorTick, x_data.toList());
_plot->setAxisScaleDiv(QwtPlot::xBottom, div);
here x_data is the vector of bin midpoints used to plot the data. The axis range is set using:
double half_bin = bin_size / 2.0;
_plot->setAxisScale(QwtPlot::xBottom, x_data.first() - half_bin, x_data.last() + half_bin, bin_size);
Any ideas what I'm missing? Depending on the number of bins, the ticks (and subsequently the labels) will occasionally line up with the mid point of the bins (or at least most of them), but as I change the bin count, the ticks will become more or less offset from the center of the bin.

How to determine if a point is within an polygon consist of horizontal and vertical lines only?

I want to find a best way because all coordinates are integer values and polygons consist of horizontal and vertical lines only. I think there may be a simple and fast method to do this.
From an asymptotic complexity point of view, a rectilinear polygon is not really simpler to process than a general one: O(N) without preprocessing, and O(Log N) after O(N Log N) preprocessing (but using a complicated procedure).
For the case of no preprocessing, the procedure is simple: consider every vertical side in turn and count those that cross the horizontal half-line from the given point (+1 upward, -1 downward). The point is inside if the final count is nonzero.
The status of points on the outline is application-dependent.
For rectilinear poygons with not too large integer coordinates, you can anyway do a little better, by "compressing" them. By two independent sorts on X and Y, you can obtain a mapping from X (or Y) to integer indexes in range [0,N). This gives the shrunk polygon below, of size NxN.
Now you can embed the polygon in an image and preprocess to label the pixels as inside/outside (by seed-filling). After filling two lookup-tables for coordinate conversion, you can obtain the status of any point in constant time O(1).
This will take O(N²+M) preprocessing time and storage, where M is the range of X and Y values.
Consider any polygon, not necessary convex, formed only with horizontal and vetical lines:
Take a point (I've drawn A,B,C,D) and draw horizontal and vertical lines passing through the point.
Let's take point A. You see the horizontal line through it crosses four (vertical) segments. Note one segment is at left and the others are at right.
For point B its horizontal line crosses also four segments, but two at left and two at right.
The conditions that a point must fulfill to be inside a polygon are:
At least one segment is horizontaly crossed at left of the point.
At least one segment is horizontaly crossed at right of the point.
Both numbers of crosses left, right must be odd.
Same three conditions for vertical lines.
So, in pseudocode it goes like this:
let nL = 0, nR = 0 //left/right counters
let nA = 0, nU = 0 //above/under counters
for each segment s(sx1,sy1, sx2, sy2) in polygon
if point is on segment
return true //or false, your choice
else if segment is vertical and pointY is inside of (sy1,sy2)
if pointX > min(sx1,sx2)
nL = nL + 1
else
nR = nR + 1
else if segment is horizontal and pointX is inside of (sx1,sx2)
if pointY > min(sy1,sy2)
nU = nU + 1
else
nA = nA + 1
//Check conditions
if nL > 0 and nR > 0 and nL is odd and nR is odd
return true
if nA > 0 and nU > 0 and nA is odd and nU is odd
return true
return false

Char's bounding box order of vertices

Google Vision API documentation states that vertices of detected characters will always be in the same order:
// The bounding box for the symbol.
// The vertices are in the order of top-left, top-right, bottom-right,
// bottom-left. When a rotation of the bounding box is detected the rotation
// is represented as around the top-left corner as defined when the text is
// read in the 'natural' orientation.
// For example:
// * when the text is horizontal it might look like:
// 0----1
// | |
// 3----2
// * when it's rotated 180 degrees around the top-left corner it becomes:
// 2----3
// | |
// 1----0
// and the vertice order will still be (0, 1, 2, 3).
However sometimes I can see a different order of vertices. Here is an example of two characters from the same image, which have the same orientation:
[x:778 y:316 x:793 y:316 x:793 y:323 x:778 y:323 ]
0----1
| |
3----2
and
[x:857 y:295 x:857 y:287 x:874 y:287 x:874 y:295 ]
1----2
| |
0----3
Why order of vertices is not the same? and not as in documentation?
It seems like a bug in Vision API.
The solution is to detect image orientation and then reorder vertices in the correct order.
Unfortunately Vision API doesn't provide image orientation in it's output, so I had to write code to detect it.
Horizontal/vertical orientation can be detected by comparing character height and width. Height is usually larger than width.
Next step is to detect direction of text. For example in case of vertical image orientation, text may go from up to down or from down to up.
Most of characters in output seem to appear in the natural way. So by looking at stats we can detect text direction. So for example:
line 1 has Y coord 1000
line 2 has Y coord 900
line 3 has Y coord 950
line 4 has Y coord 800
We can see that image is rotated upside down.
You must to reorder vertices of four poins(clockwise inverted from A to D):
A-B-C-D that:
A: min X, min Y
B: max X, min Y
C: max X, max Y
D: min X, max Y
And save to your rectangle object.
Update: You can order vertices by distance from O(0,0) for A-B-C-D order above.

Check if the line goes through wall on 2D map

I have 2d map and I want to check if line collides with any element. I need a function that can tell me if the line intersect any object on its way.
Take a look:
Red lines are not correct (function should return false), and green are (return true).
My collision map is map of boolean with 1 for wall and 0 for empty space.
How to this? I've read that I need to check if the line intersect any wall, but i have completely no idea how to do this on 2d map.
Thanx for any replies.
It depends on how your walls are represented.
If they are rectangle, then look for the line/segment intersection between your line and the 4 segments representing the rectangle.
If they are pixels, you can use the bresenham line algorithm to see if the pixels on the line are on these blocks.
If your walls are represented as line-segments you could test for intersection of line-segments as Paul Bourke describes: http://local.wasp.uwa.edu.au/~pbourke/geometry/lineline2d/
If your walls are represented as polygons you could clip your test line against the wall polygon and see if the clipping result is non-empty as Paul Bourke describes: http://local.wasp.uwa.edu.au/~pbourke/geometry/cliplinetopoly/
So, I imagined that your cells are squares... let say they're unit squares. So, if I have any coordinate, for a point like , which are floats or doubles, they are in cell .
you need to know in which cells are the endpoints of the line
walk straight from one endpoint to the other and for each cell, test if it's a wall or not
return false when a wall is found, true otherwise.
To walk from one endpoint to the other, you need to compute the delta of each axis (call delta_x and delta_y, those values are 'int' because we're talking cells here), i.e. the number of cells it goes on the vertical and on the horizontal. You take the largest of the two. You will use that largest value for your loop. Let say it's this value is D = max(delta_x, delta_y) and XX and YY are the coordinate of the cell of one endpoint.
float step = 1.0f / D;
float current_location = 0.0;
for (int i = 0; i <= D; ++i, current_location += step)
{
int cur_x = XX + current_location * delta_x;
int cur_y = YY + current_location * delta_y;
if (intersect_wall(cur_x, cur_y))
return false;
}
return true;
That's it... adapt this to your functions.

Working out positions with array indexes

I have an array that represents a grid
For the sake of this example we will start the array at 1 rather that 0 because I realized after doing the picture, and can't be bothered to edit it
In this example blue would have an index of 5, green an index of 23 and red 38
Each color represents an object and the array index represents where the object is. I have implemented very simple gravity, whereby if the grid underneath is empty x + (WIDTH * (y + 1)) then the grid below is occupied by this object, and the grid that the object was in becomes empty.
This all works well in its current form, but what I want to do is make it so that red is the gravity point, so that in this example, blue will move to array index 16 and then 27.
This is not too bad, but how would the object be able to work out dynamically where to move, as in the example of the green grid? How can I get it to move to the correct index?
Also, what would be the best way to iterate through the array to 'find' the location of red? I should also note that red won't always be at 38
Any questions please ask, also thank you for your help.
This sounds very similar to line rasterization. Just imagine the grid to be a grid of pixels. Now when you draw a line from the green point to the red point, the pixels/cells that the line will pass are the cells that the green point should travel along, which should indeed be the shortest path from the green point to the red point along the discrete grid cells. You then just stop once you encounter a non-empty grid cell.
Look for Bresenham's algorithm as THE school book algorithm for line rasterization.
And for searching the red point, just iterate over the array linearly until you have it and then keep track of its grid position, like William already suggested in his answer.
x = x position
y = y position
cols = number of columns across in your grid
(y * cols) + x = index in array absolute value for any x, y
you could generalize this in a function:
int get_index(int x, int y, int gridcols)
{
return (gridcols * y) + x;
}
It should be noted that this works for ZERO BASED INDICES.
This is assuming I am understanding what you're talking about at all...
As for the second question, for any colored element you have, you should keep a value in memory (possibly stored in a structure) that keeps track of its position so you don't have to search for it at all.
struct _THING {
int xpos;
int ypos;
};
Using the get_index() function, you could find the index of the grid cell below it by calling like this:
index_below = get_index(thing.x, thing.y + 1, gridcols);
thing.y++; // increment the thing's y now since it has moved down
simple...
IF YOU WANT TO DO IT IN REVERSE, as in finding the x,y position by the array index, you can use the modulus operator and division.
ypos = array_index / total_cols; // division without remainder
xpos = array_index % total_cols; // gives the remainder
You could generalize this in a function like this:
// x and y parameters are references, and return values using these references
void get_positions_from_index(int array_index, int total_columns, int& x, int& y)
{
y = array_index / total_columns;
x = array_index % total_columns;
}
Whenever you're referring to an array index, it must be zero-based. However, when you are referring to the number of columns, that value will be 1-based for the calculations. x and y positions will also be zero based.
Probably easiest would be to work entirely in a system of (x,y) coordinates to calculate gravity and switch to the array coordinates when you finally need to lookup and store objects.
In your example, consider (2, 4) (red) to be the center of gravity; (5, 1) (blue) needs to move in the direction (2-5, 4-1) == (-3, 3) by the distance _n_. You get decide how simple you want n to be -- it could be that you move your objects to an adjoining element, including diagonals, so move (blue) to (5-1, 1+1) == (4, 2). Or perhaps you could move objects by some scalar multiple of the unit vector that describes the direction you need to move. (Say, heavier objects move further because the attraction of gravity is stronger. Or, lighter objects move further because they have less inertia to overcome. Or objects move further the closer they are to the gravity well, because gravity is an inverse square law).
Once you've sorted out the virtual coordinates of your universe, then convert your numbers (4, 2) via some simple linear formulas: 4*columns + 2 -- or just use multidimensional arrays and truncate your floating-point results to get your array indexes.