Project Introduction
ImageFlow started out as the project for the Bachelor-Thesis by Daniel Senff. The development was continued during an internship at CRP Henri Tudor in Luxemburg and an independent coursework during his Masters program. The program is open source and can be modified to suite your own needs or be taken as a base for own applications. It's still a small project which can be handled easily by 1-2 developers, however this documentation should help to easily get into the technical solutions applied here.
The task of the application is to create a graphical user interface for the creation of ImageJ-macro using an node-based visual programming solution. The user should be able to create image-processing solution just by connecting processing units on a workspace. The constructed graph would be transformed to a one-dimensional Macro-Code and passed to ImageJ, which would do the actual image processing. The application was build around this basic dilemma and the Visual Programming paradigm.
The project began around October 2008 with the beginning of the Bachelor-Thesis of Daniel Senff. His mentor for the thesis was Prof. Kai-Uwe Barthel who published in accordance with Daniel a paper for the ImageJ conference about the basic intention of the program. Based on a rough early prototype describing the basic structure of the graph and the conversion from this virtual graph to an executable ImageJ Macro.
Based on this prototype Daniel developed ImageFlow as his project for the Bachelor-Thesis and released the first beta in March 2009 and the Bachelor-Thesis in April 2009. Interested by the conference paper describing the application, the CRP Henri Tudor invited him to continue the development for another 4 months. In Luxembourg, Daniel was joined by a colleague of his, Friedrich Maiwald. In May 2009 the first stable version was released. ImageFlow was featured in a workshop by Daniel Senff and Kai-Uwe Barthel at the ImageJConference in Luxemburg in October 2010. In Winter 2010 development was continued for another 4 months bringing several big new features.
To fulfill the tasks. The program is originally based on three major components.
Obviously the most important basis is ImageJ, which would deal with the actual image processing. The basis for the graphical workflow was VisualAp, however over the course of the project its influence decreased and many functions were implemented separately, slowly fading it out. The third component is the Swing Application Framework, which gives a skeleton for the basic application structure.
ImageJ is an open source application for image analyzing. Through its rich plugin-interface and a well-documented API it was a great basis for image-editing in Java. ImageJ has its own scripting language to perform batch tasks. These macros can be saved and integrated into the program structure. Macros can be created by two ways. Either by hand or using the limited Macro-Recorder. Imageflow was to provide a visual user interface for creating Macros.
Since the graph-interaction can be quite complex to develop from scratch it was seen to find a basis. After trying several Java-based Open-Source Frameworks for flow-processing and node-based interaction it was decided to build upon VisualAp.
VisualAp already included a lot of the functionality intended for the final application of ImageFlow. It brought the Components to draw a workspace, including the graph with units and their connections. These elements could be moved, copied, pasted, duplicated and reconnected. There was a clipboard and VisualAp delivered many of the basic graph.
However, there were a few major differences. VisualAp's unit-management was based around JavaBeans. Jar-files containing the processing units. This management was not used, but instead an own specification of defining XML-units to generate processing-units was developed.
VisualAp had the big disadvantage, that it wasn't planed as a general library and extending it without modifying the original source code was not possible. Over the course of the project more modifications became necessary so the decision was to fade out the use of VisualAp components. As of version 1.2 only few classes remain.
One of the early decisions was to base the application around a Desktop Application Framework. This framework was supposed to give a skeleton for the model-controller structure, resource management, thread handling and action-handling. Appframework developed as Specification JSR-296 by Sun. The framework was specified in 2006 and has been in development since then. It was originally scheduled to be included in Java7 and by 2008 it was already included NetBeans.