I want to algorithmically specify every pixel on the screen (full screen) or window to paint in a Java application. I want to do an animation this way.
So, for each pixel, I'll run some type of calculation to determine what color it should be. I'll do this every frame for every pixel.
What is the highest performance (capable of highest frames per second) way to do that?
I understand graphics cards are programmable, but I'd like to stick with just coding in Java for this. If there is a straightforward way to code the algorithms in Java such that they run on the graphics card, that would be great, but I want a solution that does not involve another programming language (which I think OpenCL or such does).
I've done this type of animations before using a the PixelGrabber and MemoryImageSource combination. Here you have some documentation and samples.
Thats the technique with best performance I know. You usually work in the pixel array (do the frame animation transformations) and then render the pixels in the resulting image (Don't need to invoque getPixel/setPixel methods to set individual pixels, which, in old times, was a great optimization).
Don't have any code sample of my own right now, but I can provide one later if you're interested in using this.
As a side note, old editions of the book Java The Complete Reference make plenty use of this techique for image manipulation examples.
Related
I'm looking for some way to set background image with barrel distortion effect(FishEye/FOV) for node using JavaFX. I found algorithm with pixel manipulation, but I want to find some another way(some hack) for reach it. This effect will be use for create node background high definition image changing animation(animation wil be change factor(power/value/degree?)) of this effect.
I'd like to offer an alternative approach which is much more efficient (real-time capable). Any solution which is based on direct pixel manipulations is doomed to be very inefficient especially for a "high definition image".
Instead I'd propose to use a TriangleMesh for this and use the image as its texture. You can then apply any kind of distortion you like by just manipulating the texture coordinates. This approach can be easily integrated into any 2D graphics via the JavaFX scene graph.
I am actively using this concept for on-the-fly reprojection of raster map tiles, so I know it works.
I will answer this question in the spirit that it was asked, i.e. no code.
JavaFX has an effect framework.
There is no in-built fisheye effect.
You could create your own custom fisheye effect implementation and plug it into the effect framework if you are a skilled developer.
Easier would be to apply your algorithm using a WritableImage with a PixelWriter or Canvas. Perhaps that could even plug into the effect framework (if you actually needed to do that, which you probably don't) using an ImageInput.
For an example of applying an algorithm to the pixels in an input image see:
Reduce number of colors and get color of a single pixel
Of course, you would use a fisheye algorithm (coded for JavaFX instead of the linked implementations) for a fisheye transform.
To animate use an AnimationTimer or, again for skilled developers, create a custom transition that plugs into the JavaFX animation framework.
You can add properties to your custom effect and manipulate them using additional properties defined on the custom transition you create.
Providing a complete solution is out of scope for a StackOverflow answer. To get help with individual tasks, split the problem up into different pieces, e.g. creating a custom effect, manipulating pixels to create a fisheye, animating an effect on an image or timeline, etc. Write the code and ask questions about the actual code with a minimal example for the problem portion you are trying to solve when you get stuck.
I've got a ridiculously insane Linear Algebra professor at uni who asked us this last Friday to develop a programme in Java that loads a monochrome picture and then applies an edge-detecting filter on it.
The problem is nobody in my class has got the slightest clue how to do it and I have only a week to get it done.
As I'm still trying to get my head round it and start it from scratch, does anybody have anything ready to send me so I can study it and save my semester?
Any efforts will be much appreciated.
Here's a very basic approach you might go with:
1) What is an edge in a monochrome image? One could say that it is a steep intensity gradient. If you go from black to white that is an edge, and vice versa.
2) A very simple filter operation that builds on this idea is the Sobel operator. Read up on it here: Wikipedia.
3) You'll stumble across 2 terms that may be unfamiliar to you: Kernel and Convolution. A kernel is basically a window moved over each pixel, performing an operation on the pixel's environment. In case of the Sobel 3x3 kernel, you assign a new value to the filtered image based on the pixel's direct neighbours. The convolution operation can be thought of as - among other things - an operation that moves the kernel across every pixel in the image (note: This is a gross oversimplification to get you started and technically incorrect. It should, however, give you the right idea)
4) Now the simplest way of applying a Sobel kernel to a BufferedImage is by using the ConvolveOp class. It is a prebuilt java class that takes a kernel, applies it to a given image and returns the filtered image. However, if this is for class, you might want to implement this yourself.
Here’s my task which I want to solve with as little effort as possible (preferrably with QT & C++ or Java): I want to use webcam video input to detect if there’s a (or more) crate(s) in front of the camera lens or not. The scene can change from "clear" to "there is a crate in front of the lens" and back while the cam feeds its video signal to my application. For prototype testing/ learning I have 2-3 images of the “empty” scene, and 2-3 images with one or more crates.
Do you know straightforward idea how to tackle this task? I found OpenCV, but isn't this framework too bulky for this simple task? I'm new to the field of computer vision. Is this generally a hard task or is it simple and robust to detect if there's an obstacle in front of the cam in live feeds? Your expert opinion is deeply appreciated!
Here's an approach I've heard of, which may yield some success:
Perform edge detection on your image to translate it into a black and white image, whereby edges are shown as black pixels.
Now create a histogram to record the frequency of black pixels in each vertical column of pixels in the image. The theory here is that a high frequency value in the histogram in or around one bucket is indicative of a vertical edge, which could be the edge of a crate.
You could also consider a second histogram to measure pixels on each row of the image.
Obviously this is a fairly simple approach and is highly dependent on "simple" input; i.e. plain boxes with "hard" edges against a blank background (preferable a background that contrasts heavily with the box).
You dont need a full-blown computer-vision library to detect if there is a crate or no crate in front of the camera. You can just take a snapshot and make a color-histogram (simple). To capture the snapshot take a look here:
http://msdn.microsoft.com/en-us/library/dd742882%28VS.85%29.aspx
Lots of variables here including any possible changes in ambient lighting and any other activity in the field of view. Look at implementing a Canny edge detector (which OpenCV has and also Intel Performance Primitives have as well) to look for the outline of the shape of interest. If you then kinda know where the box will be, you can perhaps sum pixels in the region of interest. If the box can appear anywhere in the field of view, this is more challenging.
This is not something you should start in Java. When I had this kind of problems I would start with Matlab (OpenCV library) or something similar, see if the solution would work there and then port it to Java.
To answer your question I did something similar by XOR-ing the 'reference' image (no crate in your case) with the current image then either work on the histogram (clustered pixels at right means large difference) or just sum the visible pixels and compare them with a threshold. XOR is not really precise but it is fast.
My point is, it took me 2hrs to install Scilab and the toolkits and write a proof of concept. It would have taken me two days in Java and if the first solution didn't work each additional algorithm (already done in Mat-/Scilab) another few hours. IMHO you are approaching the problem from the wrong angle.
If really Java/C++ are just some simple tools that don't matter then drop them and use Scilab or some other Matlab clone - prototyping and fine tuning would be much faster.
There are 2 parts involved in object detection. One is feature extraction, the other is similarity calculation. Some obvious features of the crate are geometry, edge, texture, etc...
So you can find some algorithms to extract these features from your crate image. Then comparing these features with your training sample images.
I have written a program that takes a 'photo' and for every pixel it chooses to insert an image from a range of other photos. The image chosen is the photo of which the average colour is closest to the original pixel from the photograph.
I have done this by firstly averaging the rgb values from every pixel in 'stock' image and then converting it to CIE LAB so i could calculate the how 'close' it is to the pixel in question in terms of human perception of the colour.
I have then compiled an image where each pixel in the original 'photo' image has been replaced with the 'closest' stock image.
It works nicely and the effect is good however the stock image size is 300 by 300 pixels and even with the virtual machine flags of "-Xms2048m -Xmx2048m", which yes I know is ridiculus, on 555px by 540px image I can only replace the stock images scaled down to 50 px before I get an out of memory error.
So basically I am trying to think of solutions. Firstly I think the image effect itself may be improved by averaging every 4 pixels (2x2 square) of the original image into a single pixel and then replacing this pixel with the image, as this way the small photos will be more visible in the individual print. This should also allow me to draw the stock images at a greater size. Does anyone have any experience in this sort of image manipulation? If so what tricks have you discovered to produce a nice image.
Ultimately I think the way to reduce the memory errors would be to repeatedly save the image to disk and append the next line of images to the file whilst continually removing the old set of rendered images from memory. How can this be done? Is it similar to appending a normal file.
Any help in this last matter would be greatly appreciated.
Thanks,
Alex
I suggest looking into the Java Advanced Imaging (JAI) API. You're probably using BufferedImage right now, which does keep everything in memory: source images as well as output images. This is known as "immediate mode" processing. When you call a method to resize the image, it happens immediately. As a result, you're still keeping the stock images in memory.
With JAI, there are two benefits you can take advantage of.
Deferred mode processing.
Tile computation.
Deferred mode means that the output images are not computed right when you call methods on the images. Instead, a call to resize an image creates a small "operator" object that can do the resizing later. This lets you construct chains, trees, or pipelines of operations. So, your work would build a tree of operations like "crop, resize, composite" for each stock image. The nice part is that the operations are just command objects so you aren't consuming all the memory while you build up your commands.
This API is pull-based. It defers computation until some output action pulls pixels from the operators. This quickly helps save time and memory by avoiding needless pixel operations.
For example, suppose you need an output image that is 2048 x 2048 pixels, scaled up from a 512x512 crop out of a source image that's 1600x512 pixels. Obviously, it doesn't make sense to scale up the entire 1600x512 source image, just to throw away 2/3 of the pixels. Instead, the scaling operator will have a "region of interest" (ROI) based on it's output dimensions. The scaling operator projects the ROI onto the source image and only computes those pixels.
The commands must eventually get evaluated. This happens in a few situations, mostly relating to output of the final image. So, asking for a BufferedImage to display the output on the screen will force all the commands to evaluate. Similarly, writing the output image to disk will force evaluation.
In some cases, you can keep the second benefit of JAI, which is tile based rendering. Whereas BufferedImage does all its work right away, across all pixels, tile rendering just operates on rectangular sections of the image at a time.
Using the example from before, the 2048x2048 output image will get broken into tiles. Suppose these are 256x256, then the entire image gets broken into 64 tiles. The JAI operator objects know how to work a tile at a tile. So, scaling the 512x512 section of the source image really happens 64 times on 64x64 source pixels at a time.
Computing a tile at a time means looping across the tiles, which would seem to take more time. However, two things work in your favor when doing tile computation. First, tiles can be evaluated on multiple threads concurrently. Second, the transient memory usage is much, much lower than immediate mode computation.
All of which is a long-winded explanation for why you want to use JAI for this type of image processing.
A couple of notes and caveats:
You can defeat tile based rendering without realizing it. Anywhere you've got a BufferedImage in the workstream, it cannot act as a tile source or sink.
If you render to disk using the JAI or JAI Image I/O operators for JPEG, then you're in good shape. If you try to use the JDK's built-in image classes, you'll need all the memory. (Basically, avoid mixing the two types of image manipulation. Immediate mode and deferred mode don't mix well.)
All the fancy stuff with ROIs, tiles, and deferred mode are transparent to the program. You just make API call on the JAI class. You only deal with the machinery if you need more control over things like tile sizes, caching, and concurrency.
Here's a suggestion that might be useful;
Try segregating the two main tasks into individual programs. Your first task is to decide which images go where, and that can be a simple mapping from coordinates to filenames, which can be represented as lines of text:
0,0,image123.jpg
0,1,image542.jpg
.....
After that task is done (and it sounds like you have it well handled), then you can have a separate program handle the compilation.
This compilation could be done by appending to an image, but you probably don't want to mess around with file formats yourself. It's better to let your programming environment do it by using a Java Image object of some sort. The biggest one you can fit in memory pixelwise will be 2GB leading to sqrt(2x10^9) maximum height and width. From this number and dividing by the number of images you have for height and width, you will get the overall pixels per subimage allowed., and can paint them into the appropriate places.
Every time you 'append' are you perhaps implicitly creating a new object with one more pixel to replace the old one (ie, a parallel to the classic problem of repeatedly appending to a String instead of using a StringBuilder) ?
If you post the portion of your code that does the storing and appending, someone will probably help you find an efficient way of recoding it.
I need a suggestion/idea how to create a 3D Tag Cloud in Java (Swing)
(exactly like shown here: http://www.adesblog.com/2008/08/27/wp-cumulus-plugin/)
, could you help, please?
I'd go either with Swing and Java2D or OpenGL (JOGL).
I used OpenGL few times and drawing text is easy using JOGL's extenstions (TextRenderer).
If you choose Swing, than the hard part will be implementation of a 3D transformation. You'd have to write some sort of particle system. The particles would have to reside on a 3D sphere. You personally would be responsible of doing any 3D transformation, but using orthogonal projection that would be trivial. So it's a nice exercise - what You need is here: Wiki's spherical coord sys and here 3d to 2d projection.
After You made all of the transformation only drawing is left. And Java2D and Swing have very convenient API for this. It would boil down to pick font size and draw text at given coordinates. Custom JPanel with overriden paintComponent method would be enough to start and finish.
As for the second choice the hardest part is OpenGL API itself. It's procedural so if You're familiar mostly with Java You would have hard time using non-OO stuff. It can get used to and, to be honest, can be quite rewarding since You can do a lot with it. If you picked OpenGL than you would get all the 3D transformations for free, but still have to transform from spherical coordinate system to cartesian by yourself (first wiki article still helpful). After that it's just a matter of using some text drawing class, such as TextRenderer that comes with JOGL distribution.
So OpenGL helps You with view projection calculations and is hardware accelerated. The Java2D would require more math to use, but in my opinion, this approach seems a bit easier. Oh, and by the way - the Java2D tries to use any graphic acceleration there is (OpenGL or DirectDraw) internally. So You are shielded from certain low-level problems.
For both options You need also to bind mouse coordinates s to rotational speed of sphere. Whether it's Java2D or OpenGL the code will look very similar. Just map mouse coordinates related to the center of panel to some speed vector. At the drawing time You could use the vector to rotate the sphere accordingly.
And one more thing: if You would want to try OpenGL I'd recommend: Processing language created on MIT especially for rich graphic applets. Their 3D API, not so coincidentally, is almost the same as OpenGL, but without much of the cruft. So if You want the quickest prototype that's the best bet. Consult this discussion thread for actual example. Note: Processing is written in Java.
That's not really 3D. There are no perspective transformations or mapping the text on some 3D shape (such as, say, a sphere). What you have is a bunch of strings where each string has an associated depth (or Z order). Strings "closer" to you are painted with a stronger shade of gray and larger font size.
The motion of each string as you move the mouse is indeed a 3D shape which looks like a slanted circle around a fixed center - with the slant depending on where the mouse cursor is. That's simple math - if you figure it for one string, you figure it out for all. And then the last piece would be to scatter the strings so that they don't overlap too much, and give each one the initial weight based on their frequency.
That's what most of the code is doing. So you need to either do the math, or translate the ActionScript to Java2D blindly. And no, there is no need for JOGL.
Why don't you just download the source code, and have a look? Even if you can't write PHP, it should still be possible to read it and figure out how the algorithm works.