I need to create a control with a behaviour similar to UISegmentControl that shows a list of sublayers into a super layer.
The number of these sublayers can change and I have to calculate their positions.
Here the problem... if I take a superlayer with a width equal to 31 and I want to place 4 sublayers in it, I should create 4 sublayers each wide 31/4 = 7.75. So the first layer has origin.x = 0, the second has origin.x = 7.75 the third 15.5 and the last 23.25.
Obviously these positions are not valid and they'll produce blurry layers... I can't find a way to round this value being able to fill the whole superlayer and maintaining integer values for width and origin.x, someone has a solution?
You can calculate all the origins using the exact values, and then round them off to the nearest integral. Then calculate all the widths by simply subtracting the two adjacent origins (or subtracting the total width of your parent from the origin of the final sublayer). This will produce layers that completely cover your parent, with integral coordinates, but some layers will be 1 pixel wider than others.
Related
When you make a line profile of all x-values or all y-values the extraction from each pixel is clear. But when you take a line profile along a diagonal, how does DM choose which pixels to use in the one dimensional readout?
Not really a scripting question, but I'm rather certain that it uses bi-linear interpolation between the grid-points along the drawn line. (And if perpendicular integration is enabled, it does so in an integral.) It's the same interpolation you would get for a "rotate" image.
In fact, you can think of it as a rotate-image (bi-linearly interpolated) with a 'cut-out' afterwards, potentially summed/projected onto the new X-axis.
Here is an example
Assume we have a 5 x 4 image, which gives the grid as shown below.
I'm drawing top-left corners to indicate the coordinates system pixel convention used in DigitalMicrgraph, where
(x/y)=(0/0) is the top-left corner of the image
Now extract a LineProfile from (1/1) to (4/3). I have highlighted the pixels for those coordinates.
Note, that a Line drawn from the corners seems to be shifted by half-a-pixel from what feels 'natural', but that is the consequence of the top-left-corner convention. I think, this is why a LineProfile-Marker is shown shifted compared to f.e. LineAnnotations.
In general, this top-left corner convention makes schematics with 'pixels' seem counter-intuitive. It is easier to think of the image simply as grid with values in points at the given coordinates than as square pixels.
Now the maths.
The exact profile has a length of:
As we can only have profiles with integer channels, we actually extract a LineProfile of length = 4, i.e we round up.
The angle of the profile is given by the arc-tangent of dX and dY.
So to extract the profile, we 'rotate' the grid by that angle - done by bilinear interpolation - and then extract the profile as grid of size 4 x 1:
This means the 'values' in the profile are from the four points:
Which are each bi-linearly interpolated values from four closest points of the original image:
In case the LineProfile is averaged over a certain width W, you do the same thing but:
extract a 2D grid of size L x W centered symmetrically over the line.i.e. the grid is shifted by (W-1)/2 perpendicular to the profile direction.
sum the values along W
In using mxCircleLayout, one can specify a radius. It seems, however, that the radius only affects a graph where the radius is GREATER than the default based on the graph bounds. In looking at the source code (JGraphX 3.3.1.1) for mxCircleLayout, line 230 has:
double r = Math.max(vertexCount * max / Math.PI, radius);
where "r" is used as the radius for the circle layout. Shouldn't this be
double r = Math.min(vertexCount * max / Math.PI, radius);
if I want to have a smaller radius? Perhaps I'm misunderstanding what "radius" means, but for a circle it ought to have the natural meaning. And changing the line gives me the (smaller) circle I want.
The max is used in order to make sure that the vertices do not overlap. See the comment at the start of the execute statement:
// Moves the vertices to build a circle. Makes sure the
// radius is large enough for the vertices to not
// overlap
However, this does seem to use the bounds of the largest vertex, which is not very useful if the vertices have different sizes where the maximum is much larger than the average.
I want to draw tiled images and then transform them by using the usual panning and zooming gestures. The problem that brings me here is that, whenever I have a scaling transformation of a large number of decimal places, a thin line of pixels (1 or 2) appears in the middle of the tiles. I managed to isolate the problem like this:
CGContextSaveGState(UIGraphicsGetCurrentContext());
CGContextSetFillColor(UIGraphicsGetCurrentContext(), CGColorGetComponents([UIColor redColor].CGColor));
CGContextFillRect(UIGraphicsGetCurrentContext(), rect);//rect from drawRect:
float scale = 0.7;
CGContextScaleCTM(UIGraphicsGetCurrentContext(), scale, scale);
CGContextDrawImage(UIGraphicsGetCurrentContext(), CGRectMake(50, 50, 100, 100), testImage);
CGContextDrawImage(UIGraphicsGetCurrentContext(), CGRectMake(150, 50, 100, 100), testImage);
CGContextRestoreGState(UIGraphicsGetCurrentContext());
With a 0.7 scale, the two images appear correctly tiled:
With a 0.777777 scale (changing line 6 to "float scale = 0.777777;"), the visual artifact appears:
Is there any way to avoid this problem? This happens with CGImage, CGLayer and primitive forms such as a rectangle. It also happens on MacOSx.
Thanks for the help!
edit: Added that this also happens with a primitive form, like CGContextFillRect
edit2: It also happens on MacOSx!
Quartz has a floating point coordinate system, so scaling may result in values that are not on pixel boundaries, resulting in visible antialiasing at the edges. If you don't want that, you have two options:
Adjust your scale factor so that all your scaled coordinates are integral. This may not always be possible, especially if you're drawing lots of things.
Disable anti-aliasing for your graphics context using CGContextSetShouldAntialias(UIGraphicsGetCurrentContext(), false);. This will result in crisp pixel boundaries, but anything but straight lines might not look very good.
When all is said and done, iOS is dealing with discrete pixels on integer boundaries. When your frames are reduced 0.7, the 50 is reduced to 35, right on a pixel boundary. At 0.777777 it is not - so iOS adapts and moves/shrinks/blends whatever.
You really have two choices. If you want to use scaling of the context, then round the desired value up or down so that it results in integral scaled frame values (your code shows 50 as the standard multiplication value.)
Otherwise, you can not scale the context, but scale the content one by one, and use CGIntegralRect to round all dimensions up or down as needed.
EDIT: If my suspicion is right, there is yet another option for you. Lets say you want a scale factor of .77777 and a frame of 50,50,100,100. You take the 50, multiply it by the scale, then round the return value up or down. Then you recompute the new frame by using that value divided by 0.7777 to get some fractional value, that when scaled by 0.7777 returns an integer. Quartz is really good at figuring out that you mean an integral value, so small rounding errors are ignored. I'd bet anything this will work just fine for you.
Let's say I have circle bouncing around inside a rectangular area. At some point this circle will collide with one of the surfaces of the rectangle and reflect back. The usual way I'd do this would be to let the circle overlap that boundary and then reflect the velocity vector. The fact that the circle actually overlaps the boundary isn't usually a problem, nor really noticeable at low velocity. At high velocity it becomes quite clear that the circle is doing something it shouldn't.
What I'd like to do is to programmatically take reflection into account and place the circle at it's proper position before displaying it on the screen. This means that I have to calculate the point where it hits the boundary between it's current position and it's future position -- rather than calculating it's new position and then checking if it has hit the boundary.
This is a little bit more complicated than the usual circle/rectangle collision problem. I have a vague idea of how I should do it -- basically create a bounding rectangle between the current position and the new position, which brings up a slew of problems of it's own (Since the rectangle is rotated according to the direction of the circle's velocity). However, I'm thinking that this is a common problem, and that a common solution already exists.
Is there a common solution to this kind of problem? Perhaps some basic theories which I should look into?
Since you just have a circle and a rectangle, it's actually pretty simple. A circle of radius r bouncing around inside a rectangle of dimensions w, h can be treated the same as a point p at the circle's center, inside a rectangle (w-r), (h-r).
Now position update becomes simple. Given your point at position x, y and a per-frame velocity of dx, dy, the updated position is x+dx, y+dy - except when you cross a boundary. If, say, you end up with x+dx > W (letting W = w-r), then you do the following:
crossover = (x+dx) - W // this is how far "past" the edge your ball went
x = W - crossover // so you bring it back the same amount on the correct side
dx = -dx // and flip the velocity to the opposite direction
And similarly for y. You'll have to set up a similar (reflected) check for the opposite boundaries in each dimension.
At each step, you can calculate the projected/expected position of the circle for the next frame.
If this lies outside the rectangle, then you can then use the distance from the old circle position to the rectangle's edge and the amount "past" the rectangle's edge that the next position lies at (the interpenetration) to linearly interpolate and determine the precise time when the circle "hits" the rectangle edge.
For example, if the circle is 10 pixels away from the rectangle's edge, then is predicted to move to 5 pixels beyond it, you know that for 2/3rds of the timestep (10/15ths) it moves on its orginal path, then is reflected and continues on its new path for the remaining 1/3rd of the timestep (5/15ths). By calculating these two parts of the motion and "adding" the translations together, you can find the correct new position.
(Of course, it gets more complicated if you hit near a corner, as there may be several collisions during the timestep, off different edges. And if you have more than one circle moving, things get a lot more complex. But that's where you can start for the case you've asked about)
Reflection across a rectangular boundary is incredibly simple. Just take the amount that the object passed the boundary and subtract it from the boundary position. If the position without reflecting would be (-0.8,-0.2) for example and the upper left corner is at (0,0), the reflected position would be (0.8,0.2).
Imagine there is a very very large room in the shape of a hollow cube. There are magic balls hanging in the air at fixed discrete positions of the room. No magic ball has another one exactly above it. If we take an imaginary horizontal plane of infinite area and pass through the cube, how can we be sure that the plane doesn't cut through any of the magic balls ?
The height of a magic ball is given as a function of its position (x and y). The distribution is such a way that some balls are at the same height while other are at different heights.
Let the function be
z = axy + bx + cy
where a,b,c are positive integer constants.
The positions (x-axis and y-axis values) and also the height (z) are discrete values (for simplicity, we can consider them positive integers).
If the ball distribution function was z=10xy+8x+4y, then it is impossible to have a z value of 15 or 21. So a plane at z=15 or z=21 would not cut any of the balls! In fact, in this case, any plane with a height (z = any odd number) would not cut through the balls. It is noticeable that there a some planes with height as even numbers that donot cut through the balls.
We do not want to find the heights of all the magic balls and compare it with the height of the horizontal plane, as that would be like trying all the possible combinations and would take very long time even on a computer.
Our aim is to find a fast method by which we can tell whether a given value of z (height) can be produced by any pair of (x,y) (positions).If a given z cannot be produced, then a plane at that height doesn't cut through any balls!
The question is also similar to finding whether a given number is present in a sequence produced by a function of two variables.
It would a great help if U could give me any suggestions to solve this problem. Thank You.
(I have already tried evolutionary computing like GA,PSO,DE,SA etc. The method needs to be deterministic).
It sounds like you have a lot of balls in the room. The room height is from z=A to z=B. What you're interested in is whether any are at height z. To do that without necessarily iterating through all the balls, you need to start by assuming that the range A to B is empty and iterate through the balls, marking parts of this range as full, until it is either full completely or there are no balls. In the former case, no plane will satisfy, but you haven't iterated through all the balls to know that. In the latter case, you have ranges of z in which there are no balls and you can use these to check more than one plane easily, however at the initial cost of iterating through all balls.