I've built a matrix of LEDs controlled by a Java program on my Raspberry Pi. I want to display characters on this matrix. So what I need to do is convert the characters to a two-dimensional boolean-Array (each LED is represented by one boolean).
The only way to do this I can think of is to design a separate matrix for each existing character, but this is way to much work.
Is there any way to do this differently?
You could rasterize (draw) a given font at a given point size using something like AWT or FreeType and then examine the image to see which pixels/LEDs should be on or off.
This will break down as the font size gets smaller. Below some point, you're probably better off coming up with the matrixes yourself rather than pouring a bunch of effort into something that doesn't work.
OTOH, "render-and-read" would be Much Less Boring... so YMMV.
you could load a monochrome image for a character with a pixel size regarding to your led matrix and check with two for loops, whether a pixel at a certain position is black (true) or white (false).
Related
I have the following problem: I have some serial numbers which always consist of 2 lines of 7 characters, (0-9 and A-Z), with a total of 14 characters. These serial numbers are located on the images of various products; I am able to localize these by using a lot of image processing and geometry transformation algorithms into the following form:
Now my aim is to read these serial numbers. I have first tried the Tesseract API after localizing the numbers into such tight images. Unfortunately, either I failed to adjust the API properly or this particular font is not in Tesseract's training set, since Tesseract is not able to properly parse the serial number. Then I quickly turned to custom solutions.
The basic thing to do is, since I know the aspect ratio and relative sizes of the characters, training a simple classifier (HOG + Linear SVM) on labeled character and background images (I have to do this in anyway) and then run it via a classical sliding window fashion, then apply non-maximum suppresion to remove false positive detections. This brute force approach does not seem to be very efficient for me, since 1) a lot feature extraction + classification operations have to run for each window 2) I have to manually label a lot of background (negative) samples, which include transition areas between two characters, the vertical space between two lines, pure background etc. Since I am able to localize the serial numbers into a rectangle which only includes a solid background except the characters, I thought of a simple foreground/background segmentation scheme. The first thing I tried is to convert the image into grayscale, downscale it and run a low pass filter to remove the high frequency noise and apply Otsu Thresholding. If I would be able localize each character almost perfectly, I could run a classifier just containing its bounding box and I won't need a lot of negative transition/background etc. labeled samples. From the above operation, I have the following result, with the optimal blur kernel size:
Now I am almost able to localize each character, but as you can see in the second image, due to bad lighting conditions, some noisy clutter is passed as foreground (especially around 0 and F, on the left side). Maybe some additional dilation/erosion operations on the binary image would help to reduce non-character clutter, but certainly I would not be able to completely eradicate them. My question is about any help and ideas about to how to localize the characters at that stage, after Otsu thresholding? I do know the width and height of each character (up to a small uncertainty caused by hand crafted measurements) and I also know that they always constitute two lines with 7 elements in each. I think about a connected component algorithm, which groups foreground pixels into blobs and then filter out blobs which do have bounding boxes with inconsistent widths and heights, but it is far from coding stage. I am open to any similar ideas or examples. (If it would be any help, I use OpenCV with Java).
When the characters are isolated and in a single piece, connected components is the way to go. Just ignore the tiny blobs and use the bounding boxes.
Sometimes characters will have small protrusions (like the F), which cause the characters to appear larger than they are. For fixed width fonts, you can adjust the box to that size.
Sometimes characters will be split in two or three pieces. You can regroup the pieces by gometric considerations and a priori knowledge on the text structure.
On such cases, achieving 100% reliability is a real challenge.
I am trying to process an X-ray image.
The task is to paint each bone to a different color. I've used canny filter,otsu binarization and Morphological Image Processing such as erosion, to get this effect:
Now I need to find an algorithm to color each bone. I was thinking about using connected-component labeling or flood fill but these algorithms requires closed area which will be filled with a color, but in my image there are also "almost closed" area to color. I was trying to "close each bone" with Dilation but it doesn't work.
And now I completely do not know what to do with it and how to color bones.
You can try to vectorize your image. I have done something similar and after running simple vectorization, connected components were easy to fill.
You can vectorize directly your input by eg. running Marching Squares on it. It will also create edge image.
While this might not be the exact thing you're looking for, I would recommend a simple edge-finding algorithm. The way I would do this (which may not be the best of the most efficient) is to extract the image into a 2D array of pixels. What you can do is compare the RGB values of each pixel to it's neighboring pixel and then color it a brighter color if the difference is higher. To calculate the difference you can use the 3D version of the 2D pythagorean distance formula. Finding the 'distance' between the RGB values and multiplying it by something to keep the values between 0 and 255, then replacing the pixel which you are comparing to it's surrounding pixels with a pixel with the average of this number for the 8 surrounding pixels.
If this is done correctly, it should produce a result similar to, if not identical to the one you present here.
I m making app in netbeans platform in java using Swing technology for dentist. i want to measure length of line which is drawn by user on image's of teeth? so, then Doctor can find the length of root canal of teeth.and line can also be not straight, line can be ZigZag.if any one have idea about that then share with me please.
You can use one of the many line detection algorithms to detect the existence of lines and then measure the line in pixels.
You can use an image processing library that already has these algorithms implemented, or you can implement them your self (better use a library though), this question is about image processing libraries and approaches in java.
That is not very easy because the images are taken from different angles or distances as I suppose. You will need some kind of scale in the image which length you know. Think of a tag with a size of 5mm x 5mm which is pasted on the tooth. In you application you can then measure this tag. Lets say its edge size is 200x200 Pixel. Then you know that 200 Pixels are 5mm and you have the formula to calculate the real size from the line length.
I am writing a game on Android, and it is coming along well enough. I am trying to keep everything as efficient as possible, so I am storing as much as I can in Vertex Buffer Objects to avoid unnecessary CPU overhead. However the simple act of drawing lots of unrelated primitives, or even a varying length string of sprites efficiently (such as drawing text to the screen) is escaping me.
The purpose of these primitives is menus and buttons, as well as text.
For drawing the menus, I could just make a vertex array for each element (menu background, buttons, etc), but since they are all just quads, this feels very inefficient. I could also create a sort of drawQuad() function that lets me just transparently load a single saved vertex array with data for xy/height&width/color/texture/whatever. However, reloading each element of the array with the new coordinates and other data each time, to copy it to the Float Buffer (For C++ guys, this is a special step you have to do in Java to pass the data to GL) so I can resend it to the GPU also feels lacking in efficiency, though I don't know how else I could do it. (One boost in efficiency I could see is setting the quad coordinates to be a unit square and then using Uniforms to scale it, but this seems unscalable).
For text it is even worse since I don't know how long the text will be and don't want to have to create larger buffers for larger text (causing the GC to randomly fire later). The alternate is to draw each letter with a independent draw command, but this also seems very inefficient for even a hundred letters on the screen (Since I read that you should try to have as few draw commands as possible).
It is also possible that I am looking way too deep into the necessary optimization of openGL, but I don't want to back myself into a corner with some terrible design early on.
You should try looking into the idea of interleaving data for your glDrawArrays calls.
Granted this link is for iphone, but there is a nice graphic at the bottom of the page that details this concept. http://iphonedevelopment.blogspot.com/2009/06/opengl-es-from-ground-up-part-8.html
I'm going to assume for drawing your characters that you are specifying some vertex coords and some texture coords into some sort of font bitmap to pick the correct character.
So you could envision your FloatBuffer as looking like
[vertex 1][texcoord 1][vertex 2][texcoord 2][vertex 3][texcoord 3]
[vertex 2][texcoord 2][vertex 3][texcoord 3][vertex 4][texcoord 4]
The above would represent a single character in your sentence if you're using GL_TRIANGLES, and you could expand on this idea to have vertices 5 - 8 to represent the second character and so on and so forth. Now you could draw all of your text on screen with a single glDrawArrays call. Now you might be worried about having redundant data in your FloatBuffer, but the savings will be huge. For example, in rendering a teapot with 1200 vertices and having this redundant data in my buffer, I was able to get a very visible speed increase over calling glDrawArrays for each individual triangle maybe something like 10 times better.
I have a small demo on sourceforge where I use data interleaving to render the teapot I mentioned earlier.
Its the ShaderProgramTutorial.rar. https://sourceforge.net/projects/androidopengles/files/ShaderProgram/
Look in teapot.java in the onDrawFrame function to see it.
On a side note you might find some of the other things on that sourceforge page helpful in your future Android OpenGL ES 2.0 fun!
I'm using JOGL (OpenGL for Java) for my application and I need to draw tons of strings on screen at once and my current solution is far too slow. Right now I'm drawing the strings using TextRenderer using the draw3D method and for even a moderate number of strings (around 300-500), it just kills the FPS. I started messing with drawing text onto the object textures, which is much faster, but there are a few problems with it. The first is that allocating all those textures requires a lot of memory. The second is that I need to find a way to size the texture so its only as big as the string and then map it to the object without stretching. The problem there is that all these thousands of boxes are using a single model being rendered with a call list. I'm not sure its possible to change the texture mapping for each object in that situation.
I don't mind if the text appears flat or 3D, it just has to be positioned in 3D space. I would prefer to render the text in the highest quality possible without sacrificing too much speed, since readability of the text is the most important part of the application. Also, nearly all of the strings are different, there aren't many duplicates.
So, my question: Am I going down the right path with drawing the strings on the textures, and if so, how can I overcome those 2 problems? Or is there another method that would suit my needs?
Depending on exactly how TextRenderer works - you might be able to use display lists to batch up your text drawing commands.
If TextRenderer works by having a texture of individual character glyphs and piecing together a string a glyph at a time: it'll be fine. just bookend your text drawing code with glNewList and glEndList. Once a list is defined, just use glCallList to use it.
If however, TextRenderer works by drawing complete strings into a texture and using one quad per string - display lists may not work. If the strings in one batch do not all fit within TextRenderer's cache, it will delete the least-recently used one to reclaim some space. Display lists will only recreate the OpenGL calls made, and so the work done by TextRenderer to update the string cache texture will be lost and you'll get incorrect output. From a quick scan of the source, I suspect that TextRenderer works in this manner.
To summarise: Display lists will greatly speed up your rendering, but will only if you don't overflow TextRenderer's string cache texture and don't use the TextRenderer after the display list has been defined.
If you can't meet these constraints you're going to have to go a bit hardcore and write your own text renderer that renders glyph-by-glyph - it'll then be trivial to cache the output geometry and extremely quick to re-render. There's an example of such a system here, with the tool to create a font here. It uses LWJGL rather than JOGL, but the translation between the two will be the least of your worries if you want to integrate it - it's meshed with the texture management etc.