Develop Reference

Java: ImageJ alternative

I'm looking for some kind of alternative to ImageJ (http://imagej.nih.gov/ij/). For those who don't know, ImageJ is great for analyzing and creating these tif files from scripts that the user writes. However I noticed that using it in a java project (using its jar) is pretty resource intensive. I was wondering if there was some alternative to it that was perhaps better written for developers (doesn't need a GUI but is more efficient with memory).

The ImgLib2 project is an N-dimensional processing library which was invented to overcome many of the fundamental limitations of ImageJ 1.x. Among other uses, it provides the underlying data model for ImageJ2, a new version of ImageJ for the next generation of image data. ImageJ2 also provides an "ImageJ Legacy" component that provides backwards compatibility with ImageJ1, including runtime patching so that the ImageJ1 API can run headless.
As for performance, ImageJ 1.x and ImgLib2 are both—in general—very resource efficient. If you have specific circumstances where you believe resources are being wasted, a separate question with further details (here or on the ImageJ mailing list) would be a good course of action.
Another programmer-friendly library is the Insight Toolkit (ITK), written in C++. It is also mature, N-dimensional and resource efficient.

Take a look at Marvin Image Processing Framework. Main aspects:
Pure Java framework.
Extensible via plug-ins SDK. Current plug-ins here.
Multithreaded image processing (multiple threads in the same image, in different regions).
Unit testing for image processing.
Camera and video file processing through Java CV.
Process video frames as easy as processing images.
Components for integrating with Swing (MarvinImagePanel and plug-ins parameters)
Suitable for server side processing in J2EE application.
Stable. Already used by companies and universities. Some publications here.
Some answers using Marvin on Stackoverflow:
A: How to detect a Christmas Tree?
A: how to merge Images and impose on each other
A: Coffee beans separation algorithm
A: Detecting multiple images in a single image
A: 2D Shape recognition algorithm - looking for guidance
A: How to find corner co-ordinates in this image?

JavaCV Vs OpenCV from Runtime point of View

I am building an Android App that includes image processing techniques. From the Runtime point of view, which is better JavaCV or OpenCV ?

Their runtime overhead seems to be about the same, but the android-opencv wrappers do not give access to raw data via direct NIO buffers, rendering custom processing in Java a lot less efficient. JavaCV is more efficient for those tasks. Being the author of JavaCV, I also like its API better :) It's closer to the original C/C++ API than android-opencv.
EDIT: Another difference is that android-opencv forces users to use the NDK and JNI to write functions. Since JavaCV is based on JavaCPP, we can write native functions more easily without having to deal with neither the NDK nor JNI.

Writing native code using Android NDK will usually be much faster than using the SDK.
You can find nice tutorial here, using opencv with NDK. Notice that with NDK framework you have access to openGL functions.

JavaCV is just a Java wrapper around the native OpenCV library. OpenCV does provide a Java/SWIG binding. I have used both bindings and didn't see a significant difference between the two.
If you are writing a native only app go with native OpenCV.

Computer vision, C++ OR Java

I'm a complete newbie in the computer vision world and recently I implemented some examples using OpenCV with Java. I'm impressed with the potential this area has and wish to continue learning more.
I learned that OpenCV is written in C++ and while Java has a wrapper (JavaCV) I understood that the applications in Java are slower than in C++ and most enterprise application are written in C++.
My question is this: I have few years of experience in Java and I feel very comfortable to write any application with it; would it be smart to move to C++ to learn CV or should I stick with Java and use its wrapper.

Computer vision is a demanding area - and while it is true that you'd best stay with what you know, and move to opencv only if performance is needed, another truth is that you'll need to go deep into mathematics, pointers and algorithms to learn and build a good computer vision app. And to do that in Java can be more cumbersome than learning c++.
So, if all you want to do is to apply a filter over an image for some school project - go for Java. But if you want to stay more with OpenCV, to learn vision algorithms or to write your own, my strong suggestion is to learn C++ - isn't that scary!
A reason to write native code is flexibility - you'll want to do all kind of tricks that are difficult or performance-killers in Java.
Shortly speaking, learning C++ is much simpler than computer vision. And OpenCV is not just a library you want to call to do some processing out there. It's bleeding edge technology - you'll want to understand it, to hack into it, to build over it, to go through the code, much more than call someJNIfunc();
And if you do so, please be aware that OpenCV offers two interfaces - one for C and one for C++. And while they offer the same functionality, the C++ one is much like Java - with automatic memory management and more sweeties. You can refer to this post to see the differences

I suggest sticking with what you're comfortable with for now. Only switch to C++ when you find that it doesn't expose certain APIs you want or performance actually becomes a problem. Right now, you're in the learning phase.

JavaCV uses a wrapper called JavaCPP to call OpenCV from Java programs. JavaCPP automatically generates temporary native libraries that form a bridge used by JNI to let Java programs call the OpenCV native libraries.
The solution is elegant and it works well, but is quite finicky about installing just the right versions and having classpaths set correctly. You can get a glimpse of the difficulties people face at the JavaCV discussion forum, and at http://code.google.com/p/javacv/wiki/Windows7AndOpenCV.
I got this working with OpenCV-2.3.1 on XP, Windows 7, and Ubuntu 10.11, and still it took me several days to get it all updated to OpenCV-2.4.2. ffmpeg is especially tricky to get right across all platforms.
There is little or no speed overhead if you are using Java for high level program control because image objects and list-based data structures are maintained on the native side through pointers. One pitfall is knowing who is responsible for releasing allocated memory, so be prepared for VM crashes with complicated programs.
There is a bit overhead in transferring data objects to the Java side. I find that it takes about 1 microsecond to copy a keypoint location into a Java-side Point object. This doesn't sound like much but in a real-time application with thousands of keypoints it can make a difference. We also copy JavaCV IplImage objects to Java through ByteBuffers. This takes a millisecond or less so is quite feasible for real-time use.
In our case, we have a substantial body of Java code to leverage against OpenCV. And Java's garbage collection makes many things much much easier. I are satisfied that the overhead of learning JavaCV has been well worth it.
I found it necessary to build the project in Eclipse and compile JavaCV from source instead of using javacv.jar. (You'll need the other .jar files though.) This lets you examine exceptions to track down library version and classpath errors. And the JavaCV source is needed to understand how JavaCV exposes the OpenCV API.

How much time is spent in the OpenCV library and how much time is spend in your program? If your program entirely in C++ it cannot reduce the time spent in your program (outside the library) to less than nothing. e.g. if you spend 99% of your time in the library, using C++ cannot make it more than 1% faster.

For simple programs, Java and C++ doesn't make any significant difference in speed. But for a large code with lot of computational complexity, C++ turns out to be faster.
Wrappers do have a problem of overhead. But this will be negligible for a small program. If you write a complex code in Java, it wont be easy to rewrite it into C++. This is because of the large no of functions available in Java which will be so much different from C++.
Whether you should use Java or C++ for OpenCV depends on your motive.
If you seriously want to lean OpenCV and work on some big projects , I suggest you to move on to C++. But if you are looking for having just some fun with OpenCV, it will be better to stick to what you know.

Among C++ or Java, better use C++. I have almost no experience in Java, but the reason I would recommend C++ is its common usage among ML&CV libraries.
One of the best solution of powerful and flexible computer vision application may be next sequence:
training a model using flexible Python and popular machine learning libraries;
storing pre-trained weights;
rewriting the best model architechture to C++ using OpenCV library with useful, but not extensive Mat class or compiling to C++ ML model;
compiling with definite specification of your device processor.
Advances of this solution are application work speed, code safety, development speed and compatibility with many devices.
Moreover, Python Tensorflow and other models could be loaded to C++, e.g. PyTorch.
Besides, it is much more easier to get help from CV community with the C++ OpenCV code.
Disadvantages are tons of development problems and development speed (which may not be omitted with Java), sometimes strictful flexibility limits of OpenCV lib, and many others you may not think of at the beginning.

Java image manipulation libraries?

Any suggestions for Java image manipulation libraries? I want to find a way of getting the coordinates of say, a line.
Thanks.

IMAGEJ: http://rsbweb.nih.gov/ij/
BoofCV: http://boofcv.org
Fiji: http://fiji.sc/wiki/index.php/Fiji
Rapidminer with IMMI: http://www.burgsys.com/image-mining

Haven't used it myself, but ImageJ seems to be a pretty good choice for image analysis and processing.

After reading your comments it seems you need Vector manipulation stuff.
JTS is very popular in this field. Take a look at it - http://www.vividsolutions.com/jts/jtshome.htm . JTS Topology Suite is an API of 2D spatial predicates and functions. Also its Free and Open Source.
Your question is bit confusing. When you say "Image Manipulation" many people will think of scalars.

see following website for more info
http://www.jhlabs.com/

Java is fine for vector calculations on modern hardware. Unfortunately, raster libraries written purely in Java (e.g. ImageJ) is much slower compared to their native counterparts. From what I can see, this happens because:
It's impossible to use vector CPU instructions;
Extra bounds checks when iterating over pixel arrays;
Garbage Collector that may start working in the middle of your algorithm.
After trying several approaches, we ended with a native library based on FreeImage and TurboJPEG that does processing for us. Our java app (Visual Watermark) calls it via JNI interface.

HPC (mainly on Java)

I'm looking for some way of using the number-crunching ability of a GPU (with Java perhaps?) in addition to using the multiple cores that the target machine has. I will be working on implementing (at present) the A* Algorithm but in the future I hope to replace it with a Genetic Algorithm of sorts. I've looked at Project Fortress but as I'm building my GUI in JavaFX, I'd prefer not to stray too far from a JVM.
Of course, should no feasible solution be available, I will migrate to the easiest solution to implement.

If you're interested in HPC with GPUs then perhaps you can look jCuda. This provides Java bindings for CUDA, along with access to CUDA FFT, CUDA BLAS and CUDA DPP. I haven't seen any performance reports on this library so I can't guarantee it will be very good.
Beyond that, I'm not really sure. If you're interested in doing this type of stuff as an educational exercise then Java should be good enough, but if you have a serious need for HPC then you're probably going to want to implement in C and use the Java Native Interface to communicate with it.

Morten Nobel Joergensen has a blog post showing how to create a Mandelbrot Set using JOGL - Java Bindings for OpenGL
However if you want generic computing, rather than graphics, then you'd be after the Java bindings for OpenCL, from which you can chose from JOCL, or JOCL or JavaCL.
Wikipedia's page shows how OpenCL can be used to compute a fast fourier transform.

Parallel Colt might be of interest.

Have a look at JPPF, it is a very nice and mature open source Java grid computing environment