I couldn't find any satisfying answer on that topic. I want to make a program that will get snapshots from camera above the pool table and detect balls. I am using OpenCV and Java. My algorithm now is basically:
blurring image -> converting RGB to HSV -> splitting into 3 planes -> using Canny() on H plane -> using HoughCircles() method to detect balls
This algorithm detects balls quite well, it has problem with two balls only (green and blue, because background of the table is green). But I want to go one step further and:
Detect if the ball belongs to stripes or solids
Set an ID of every ball, stripes would have for example 1-7 and solids 8-14, every ball would have unique ID that doesn't change during the game
Do you have any idea how to implement task #1? My idea is to use inRange() function, but then I'd have to prepare a mask for every ball that detects that one ball in specified range of colors, and do this detection for every ball, am I right? Thanks for sharing your opinions.
#Edit: Here I give you some samples of how my algorithm works. I changed some parameters because I wanted to detect everything, and now it works worse, but it still works with quite nice accuracy. I`ll give you three samples of original image from camera, image where I detect balls (undistorted, with some filters) and image with detected balls.
Recommendation:
If you can mask out the pixels corresponding to a ball, the following method should work to differentiate striped/solid balls based on their associated pixels:
Desaturate the ball pixels and threshold them at some brightness p.
Count the number of white pixels and total pixels within the ball area.
Threshold on counts: if the proportion of white pixels is greater than some threshold q, classify it as a striped ball. Otherwise, it's a solid ball.
(The idea being that the stripes are white, and always at least partially visible, so striped balls will have a higher proportion of white pixels).
Sample Testing:
Here's an example of this applied (by hand, with p = 0.7) to some of the balls in the unrectified image, with final % white pixels on the right.
It looks like a classification threshold of q = 0.1 (minimum 10% white pixels to be a striped ball) will distinguish the two groups, although it would be ideal to tune the thresholds based on more data.
If you run into issues with shadowed balls using this method, you also can try rescaling each ball's brightnesses before thresholding (so that the brightnesses span the full range 0, 1), which should make the method less dependent on the absolute brightness.
Related
I'm working on a project at school, which basically is: writing an application to make a drone fly autonomously, and through scanning QR-codes hung up on walls, be able to navigate through a room in order to complete a certain task.
What I am currently working on, is for the drone to detect cardboard boxes (working as obstacles). These boxes are white, and have a blue circle on them. How I'm planning to solve this, is by scanning the frame for colors and squares:
If the drone detects a square, check if it's white. If it's white, check if it contains a blue circle. If it does, I can say that it most likely is a cardboard box.
This is what the box looks like:
If anyone would be able to provide some pointers as to how I can start working on the color detection, I would be very happy!
PS: I haven't provided any code, since I don't really know what to provide. I would be more than happy to provide some if needed
UPDATE: for anyone stuck at the same problem as I, a fellow student provided an excellent link for my exact situation:
http://opencv-java-tutorials.readthedocs.io/en/latest/08-object-detection.html
I would go from a different angle to do this by detecting the blue circle first.
Detect base colors
see RGB value base color name
Select all blue pixels neighboring white or gray-ish ones
As your circlehas black border then you have to select all blue pixels near white,gray,black... just to be sure. This is the result (Green are selected pixels):
another (more robust) possibility is to select all black pixels neighboring white and blue at the same time.
do a connected components analysis
so merge all connected pixels into polylines
For each polyline decide if it is circle/ellipse/oval
that can be done by investigating angle between line segments. If has sharp spikes then sharp edges are present and it is not an oval. If the circumference is too far from circle/elipse/oval computed from its bounding box then it is not oval but some more complicated curvature.
For each oval decide if it is filled with blue
so just flood fill mask of the oval circumference and compare how many pixels are int the original image blue against those that are not. if the ratio is closer to 100% blue then it is filled blue oval shape....
As your marker has also some features inside you can compute the ratio of all base colors inside it to more accurately detect the marker.
Look at Algorithms: Ellipse matching for some additional ideas.
now you can similarly check if the background is white/gray-ish
There are a lot of other possible approaches like OCR and character similarity or based on FFT/DCT, Hough transform for circles... also you are not bound only to geometric properties comparation instead you can compare histograms...
I'm using slick2d to render an Animation, but using anti-aliasing
Without AA, the movement is choppy, as one would expect for something without AA.
I turn on AA in my game's preRenderState with:
g.setAntiAlias(true);
This leads to:
Note the diagonal line in the center, presumably caused by the two triangles that render the rectangle not meeting precicely. How can I remove that while still using AA to smooth my movement? I found http://www.java-gaming.org/index.php?topic=27313.0 but the solution was "remove AA" which I am reluctant to do.
This looks suspiciously like artifacts due to GL_POLYGON_SMOOTH.
When you use that (deprecated) functionality, you are expected to draw all opaque geometry with blending enabled and the blend function: GL_SRC_ALPHA_SATURATE, GL_ONE. Failure to do so produces white outlines on most contours (aliased edges, basically).
Chapter 6 of the OpenGL Redbook states:
Now you need to blend overlapping edges appropriately. First, turn off the depth buffer so that you have control over how overlapping pixels are drawn. Then set the blending factors to GL_SRC_ALPHA_SATURATE (source) and GL_ONE (destination). With this specialized blending function, the final color is the sum of the destination color and the scaled source color; the scale factor is the smaller of either the incoming source alpha value or one minus the destination alpha value.
This means that for a pixel with a large alpha value, successive incoming pixels have little effect on the final color because one minus the destination alpha is almost zero. With this method, a pixel on the edge of a polygon might be blended eventually with the colors from another polygon that's drawn later. Finally, you need to sort all the polygons in your scene so that they're ordered from front to back before drawing them.
That is a lot of work that almost nobody does correctly when they try to enable GL_POLYGON_SMOOTH.
Every time you enable anti-aliasing in Slick2D, it should look like this.
g.setAntiAlias(true);
GL11.glBlendFunc(GL11.GL_SRC_ALPHA_SATURATE, GL11.GL_ONE);
Basically same as Andon's answer, but with code that should solve the problem.
Note that with this whatever you draw first will be on top, rather than what you draw last. So you may need to reverse rendering order.
I am 11 years old, and I program with Java, HTML, and CSS. Well what I have is a game, and its a Minecraft 2D Platformer.
Well I have some water to the side, and what I want to do is when the player intersects that water, I want it to slow down. Here is a example if there was a method to do this, in case you still don't understand my goal.
if (player.intersectsColor("0026FF"))
playerSpeed = 2;
else
playerSpeed = 3;
I suggest you represent the water not by its color but by its location. That way you can check whether the player is in a "tile" representing water, and adjust the speed accordingly.
This you can do with simple comparison on the x/y coordinates (adjusted for the size of the "tile"/"player")
If you don't have nice meshy tiles, but curves/polygons, you will need to read up on geometry and how to calculate (possibly curved) line intersection. The exact algorithm will depend on the curve used.
The reason I discourage you from using the color itself for the intersection many twofold:
"Intersecting" on a single color limits your ability to dynamically color the terrain/objects later
You cannot have two different terrain.object type with the same color
Having the color (e.g. brown) of the terrain/object does not tell you which blue terrain/object the player ran into (e.g. is it the first or the second chest?)
If you really want to represent the terrain with colors, you can translate the players in-game coordinates to screen coordinates and see what color pixel you have at that coordinate on the screen (before the player was rendered on the scene), but this is messy.
I'm using Java Graphics2D to generate this map with some sort of tinted red overlay over it. As you can see, the overlay gets cut off along the image boundary on the left side:-
After demo'ing this to my project stakeholders, what they want is for this overlay to clip along the map boundary with some consistent padding around it. The simple reason for this is to give users the idea that the overlay extends outside the map.
So, my initial thought was to perform a "zoom and shift", by creating another larger map that serves as a "cookie cutter", here's my simplified code:-
// polygon of the map
Polygon minnesotaPolygon = ...;
// convert polygon to area
Area minnesotaArea = new Area();
minnesotaArea.add(new Area(minnesotaPolygon));
// this represents the whole image
Area wholeImageArea = new Area(new Rectangle(mapWidth, mapHeight));
// zoom in by 8%
double zoom = 1.08;
// performing "zoom and shift"
Rectangle bound = minnesotaArea.getBounds();
AffineTransform affineTransform = new AffineTransform(g.getTransform());
affineTransform.translate(-((bound.getWidth() * zoom) - bound.getWidth()) / 2,
-((bound.getHeight() * zoom) - bound.getHeight()) / 2);
affineTransform.scale(zoom, zoom);
minnesotaArea.transform(affineTransform);
// using it as a cookie cutter
wholeImageArea.subtract(minnesotaArea);
g.setColor(Color.GREEN);
g.fill(wholeImageArea);
The reason I'm filling the outside part with green is to allow me to see if the cookie cutter is implemented properly. Here's the result:-
As you can see, "zoom and shift" doesn't work in this case. There is absolutely no padding at the bottom right. Then, I realized that this technique will not work for irregular shape, like the map... and it only works on simpler shapes like square, circle, etc.
What I want is to create consistent padding/margin around the map before clipping the rest off. To make sure you understand what I'm saying here, I photoshopped this image below (albeit, poorly done) to explain what I'm trying to accomplish here:-
I'm not sure how to proceed from here, and I hope you guys can give me some guidance on this.
Thanks.
I'll just explain the logic, as I don't have time to write the code myself. The short answer is that you should step through each pixel of the map image and if any pixels in the surrounding area (i.e. a certain distance away) are considered "land" then you register the current pixel as part of the padding area.
For the long answer, here are 9 steps to achieve your goal.
1. Decide on the size of the padding. Let's say 6 pixels.
2. Create an image of the map in monochrome (black is "water", white is "land"). Leave a margin of at least 6 pixels around the edge. This is the input image: (it isn't to scale)
3. Create an image of a circle which is 11 pixels in diameter (11 = 6*2-1). Again, black is empty/transparent, white is solid. This is the hit-area image:
4. Create a third picture which is all black (to start with). Make it the same size as the input image. It will be used as the output image.
5. Iterate each pixel of the input image.
6. At that pixel overlay the hit-area image (only do this virtually, via calculation), so that the center of the hit-area (the white circle) is over the current input image pixel.
7. Now iterate each pixel of the hit-area image.
8. If the any white pixel of the hit-area image intersects a white pixel of the input image then draw a white pixel (where the center of the circle is) into the output image.
9. Go to step 5.
Admittedly, from step 6 onward it isn't so simple, but it should be fairly easy to implement. Hopefully you understand the logic. If my explanation is too confusing (sorry) then I could spend some time and write the full solution (in Javascript, C# or Haskell).
I'm working on making a 2D isometric engine in Java because I like suffering, I guess. Anyways, I'm getting into collision detection and I've hit a bit of a problem.
Characters in-game are not restricted to movement from tile to tile - they move freely. My problem is that I'm not sure how to stop a player from colliding with, say, a crate, without denying them access to the tile.
For instance, say the crate was on .5 of a tile, and then the rest of the crate was off the tile, I'd like the player to be able to move on to the free .5 of the tile instead of the entire tile becoming blocked.
The problem I've hit is that I'm not sure how to approximate the size of the footprint of the object. Using the image's dimensions don't work very well, since the object's "height" in gamespace translates to additional floorspace being taken up by the image.
How should I estimate an object's size? Mind, I don't need pixel-perfect detection. A rhombus would work fine.
I'm happy to provide any code you might need, but this seems like a math issue.
From the bounding rectangle of the sprite, you can infer the height of a rhombus that fits inside, but you cannot precisely determine the two dimensions on the floor, as each dimension contributes equally to width and height of the sprite. However, if you assume that the base of the rhombus square then you can determine the length of its side as well.
If the sprite is W pixels wide and H pixels high, the square base of the rhombus has a side of W / sqrt(3) and the height of the rhombus will be H - (W / sqrt(3)). This image of some shapes in isometric projection can be helpful to understand why these formulas work.