I'm working on a 4-point image transformation for an application. The user would either drag each corner around to create a valid quadrilateral shape, or use its "bounding box" to resize it vertically, horizontally, and proportionally.
So far, I have the image transformation part working. However, I'm having a hard time imposing limitations to it so that...
The vertices doesn't cross over each other. In another words, I don't allow the user to create an hour-glass shape. It must always be a quadrilateral.
Likewise, the angle between each corner must be greater than 0. Otherwise, the vertices will end up in a line.
It has a minimum size on this image. That is, each corner has to be a certain distance away from each other, and their opposing lines.
The user cannot "flip" the image to its backside. The 4 corners (p1, p2, p3, and p4) must appear in clockwise order.
Concave kite shapes and triangles are valid.
I was wondering if there was a formula or a paper regarding these issues. I do currently have the formulas for finding if 2 line segments intersect (and where), as well as finding the closest point on a line to another point. Most of my implementations hasn't been user-friendly as I liked, as the corners would jump all over the place when imposing restrictions.
P.S. I'm using C# for this project, with DirectX. The application is solely 2D, however.
My suggestion is not to impose restriction but just drawing say just a red wireframe polygon if for you it's unacceptable.
It's more or less like when programmers put restriction on form input fields e.g. begin date must come before end date and don't allow you to type in a date in the begin field that's after the date in the end field... forcing users to tab to end field first, then entering the end date, then tabbing back to the begin field to enter the correct begin date.
Just showing the fields in red is MUCH more usable... and actually requires less coding.
Trapping user mouse movements is rarely a sensible idea. If you can't apply what user is asking just make this evident instead of constraining the movement... may be the user is moving the first vertex and wants to move another vertex later to a position that will make your transform valid (exactly like the two date fields example).
If you really think you MUST prevent invalid positions at all times (and that for example will forbid the user from flipping the image even if your transform would allow a flipping operation without problems) then the simplest solution that comes to my mind is just having an isValid() function and just not moving the keypoint to the new position if it's invalid.
Having code that "slides" around invalid state space areas is IMO quite difficult to handle nicely, also because invalid areas are going to be quite close to "almost invalid" areas.
Even in case "sliding" is a requirement I'd probably go for implementing an implicit isValid() approach by doing a local search around the keypoint position to find what is the closest valid point to the point the user is asking for.
Explicitly computing all sliding possibilities would be a nightmare to get correct and also to maintain if you need to change something in the transformation algorithm (and consequently in what is valid and what is not).
When you start out, and each time the user moves a handle, determine the set of horizontal and vertical lines that the other handles cannot pass, and enforce those boundaries during a drag. This will solve your first problem.
For the second, when the mouse moves during a drag, calculate the distance between the cursor and each of the other 3 handles; if it is less than your defined minimum distance then move the handle in a circular path around the other handle(s).
Related
I've searched the Internet and maybe I'm missing some correct keywords but I managed to find nothing like this. I only found the poly-lines (or just the lines) which are not exactly the graphs. I would like to generate a graph outline (of radius r) as seen in the picture. Is there something already available? I would like to avoid reinventing the wheel so to speak.
If anyone can at hint me at something or at least at some basic principle how to do it it would be great. Otherwise I'll "invent" one on my own of course.
Optimally in C#.
Update: I need to calculate outline polygon, not just visually draw it. The green points represents the resulting polygon. Also the "inner" holes are ignored completely. Only one outline polygon should be enough.
Update 2: Better picture to show some more extreme cases. Also the edges of graph never overlap so no need to accommodate for that.
Update 3: Picture updated yet again to reflect the bevel joins.
First, for every "line piece" from point A to B, generate the rectangle to it (all 4 points as "path", so to say). Then search two overlapping rectangles and merge them:
Merging is a bit complicated, the idea: Start with calculating the angle of all 8 lines (eg. if the rectangles are traversed clockwise). Then traverse one rectangle until the first line-line-intersection, check with the angles which direction is "outside", and move along the crossing line of the second rectangle ... until you arrive at the start point again => Now you traversed the shape of both together (and hopefully saved it somewhere).
Merge until only one large piece is left (or multiple non-overlapping pieces). In theory, starting from any point, you can traverse the whole shape, but there´s another problem: Holes are possible.
If one shape has two or more disjuct sets of points (where no point from set 2 is reachable from set 1 and vice-versa), all but one disjunct path is of a hole. An easy possibility to get the real outer border is to search for an extremum, ie. the point with the largest or smallest X or Y coordinate (only one of the 4 combinations in enough). This point surely is a part of the outer border.
My current project has required me to learn face detection/tracking and image processing, given my experience in c#, I chose Emgu CV as my choice library for face detection and tracking. From what I've learned so far, I can do face detection and tracking, and basic image processing.
My goal is to be able to place virtual hair on the detected face. What I want to achieve is similar to [this video]: http://www.youtube.com/watch?v=BdPmECfUFcI.
What I would like to know is the technique(s) to use in handling hair placement for different kind of hairstyles on the detected face. In what image format do I store the the hair?
After watching the video I noticed it considers the head as a flat rectangle and not as a rectangular prism (the 3D object), so it doesn't consider the use of perspective transformations and I will not consider it too. This is a limitation but serves as a decent first step in doing such placements. Note that it is not a simply matter of taking perspective into consideration, your face tracking algorithm also needs to be able to handle more complicated configurations (the eyes might not be fully visible, for example).
So, the first thing you want is a bounding rectangle aligned according to the angle the eyes make with the x axis, illustrated in the following right figure (the red segment indicates the connection between the eyes). The left figure shows a typical bounding box aligned to the axis, which doesn't serve for this problem.
The problem is also simplified after you consider the head is symmetric, so you know the top middle point in the above figure is the middle of the top of your head. Also, considering that a typical head will likely be larger at top than at bottom, then you have something like in the following figure where the width of the rectangle is close to the width of the forehead. You could also consider a bounding rectangle on only upper half of the head, for example.
Now all that is left is positioning some object in this rectangle. For that, you need to augment the description of this object to be positioned so it is not purely pixels. We can define "entrance width" (EW) and "entrance middle point" (EM). This EW establishes the width needed in the other rectangle (the head one) to position it. So, if EW is smaller than the needed value, you upscale this object, respectively for when EW is larger. Note that the full width of the head's rectangle is usually an overestimation to position this object, so you can experiment with percentages of the width. The EM value is useful to know how you will position this object over the head. In the following figure, EW is the horizontal blue dashed horizontal, and EM is the middle point on it. The vertical blue line indicates how much over the EM you want to move this object inside the top segment of head's rectangle.
The only other special thing this object needs is a value that is considered as background. So when painting this object it is easy to know whether to make a point fully transparent (the background value) or fully opaque (anything else). This was the sketch I had in mind of what needs to be basically done.
I am working with C# OpenTK, but any code in C++ OpenGL is fine, i understand it.
I have a list of Markers. A Marker is defined as a 2 coordinate, and a pointer to the next marker in the loop. Essentially, if you were to follow the path of those pointers, you would eventually reach the Marker you started with. This is how shapes are initially defined.
One of those 'loops' may not be all the markers in the list. Multiple 'loops' may be contained. Take the letter 'A' for example:
This shape here would be defined by 2 'loops'. One is the outline (8 Markers), while the other loop would be the triangle within (3 Markers).
(Marker - Pointer)
1-2, 2-3, 3-4, 4-5, 5-6, 6-7, 7-8, 8-1
9-10, 10-11, 11-9
I need a method that will allow me to draw something like this to the screen. The solutions stated here would correctly solve the issue on a bitmap level (going through pixel after pixel to check if it within the polygon), however would be quite inefficient, especially given the fact that these markers shall be moved continuously at run time.
It is required that these shapes should be able to include things such as the triangle in an A (inverting), and preferably would allow for overlapping boundaries of the 'loops', but this second thing is not a necessity.
I'm guessing the direction taken will either be some sort of conversion to triangles, or some fancy trick with built in OpenGL features.
You're looking for triangulation with holes.
Check out the General Polygon Clipper (GPC).
I'm trying to manage about multi-touch. So, I'm trying to separate the behavior of touchs. Suppose the person want to zoom their picture, they need to pinch in order to zoom it. However, two fingers which two touch points are so distance will not be allow to zoom as I shown with figure below:
How can I separate that. Is there any function to do that ?
Regards,
C.Porawat
Is this about distinguishing one-handed vs. two-handed scaling manipulation, or about imposing certain minimum/maximum zoom factors for manipulated objects?
In the first case, this is not (reliably) possible. To my knowledge, contacts do not carry identifiable information that would allow you to tell fingers of one hand apart from fingers of the other hand. As Cody noted, it is also NOT desirable for scaling gestures.
However, I take it that what you're really trying to achieve is to prevent the user from scaling an object to extreme dimensions. As the ManipulationDelta event that you receive (preferable to raw touch events in your case, as you'd have to derive an incremental transform matrix/scale factor by yourself) exposes a DeltaManipulation.Scale property, you should be able to inspect this and the current scale factor of the manipulated object (as specified by the magnitude of a row vector of your object's transformation matrix; don't remember off the top of the head if there's a convenience function to retrieve it for you?) to impose minimum/maximum scaling factors.
It might even be possible that some manipulation processor or UIElement has corresponding bounds pre-built for you.
I have some problems getting an algorithm for my game to work and hope someone here can help me. Google didn't seem to be a good help as most solutions just work for full tiles.
In the game units can occupy different positions inside a tile, i.e. they can be in the upper left corner, center, bottom right, ... position of tile (2/3), i.e. (2.2/3.1), (2.5/3.5), (2.8/3.9).
If they move from position (2.2/3.1) to (5.7/4.1) i require a check to see if there is an obstacle in the path.
My current algorithm is:
Starting from (2.2/3.1)
Calculate the angle of the movement (i.e. 70 degree)
Move 0.1 steps in that direction
Check which tile i'm on (floor(p.X)/floor(p.Y))
Repeat from 2
This algorithm works but to me it doesn't look very efficient as an obstacle can be only a full tile, not a part of a tile (units don't collide). If i increase the step size i begin to miss tiles that are only crossed slightly (i.e. you only cross the lowest left corner). Even with a step size of 0.1 it's still possible to miss an obstacle.
I tried to find a solution to take the sub map (all tiles with the corners (floor(start.X)/floor(start.Y)) and (ceil(start.X)/ceil(start.Y)), move through every tile and check mathmatically if it gets crossed. Sadly i seem to lack the required math knowledge for this check.
My last idea was to take all 4 borders of a tile as a line and do line-intersection but that seems to be slower than my original approach.
Any hints?
Thanks.
Instead of tracing the path by stepping along the line - you want to jump right to the next possible tile (the border). This can be calculated fairly simply. I will use your sample numbers above.
Calculate the line eqn (y= .286x + 2.471)
You are starting on tile 2,3 and moving towards tile 5,4. So calculate the y value when x goes to 3 (the border to the tile immediately to the right). It is 3.329.
Then calculate the x value when y goes to 4 (the border to the tile immediately above). It is 5.346.
Starting at 2,3 and moving right gets to 3,3.329. Moving up gets to 5.346,4. You intersect on the right(moving 2 -> 3 on x doesn't move a tile on y). You don't intersect above until you are on tile 5 in the x.
The tile calculated in 4 becomes your new comparison (3,3). Repeat from step 2.
This process only incurs one calculation per tile moved (regardless of your precision or how big the tiles are) and is exact. Note that the values calculated can be stored and reused instead of blindly calculating both intersections over and over. In the above we know (step 4) that we don't move up a tile until x=5. So the entire path can be inferred without another calculation (2,3 -> 3,3 -> 4,3 -> 5,3 -> 5,4).
It is also possible to precalculate all the transistions instead of doing them stepwise although this would only be beneficial if you always need the entire path (you don't since you want to stop processing once you find an obstacle).
Two caveats. Be careful about signs and which way the line is going - many a bug happen by not paying close attention to negative slopes. Also, using reals you almost never will cross diagonally (two borders at once) but you should be aware of it (handle it in the code) just in case.
There is a name for this method but I can't remember it off the top of my head. I believe it might be from Game Programming Gems series but maybe someone else can provide a better reference.