Entries by Daniel Senff

I took a break for a couple of months, but I'm back on track. The next version will be mostly maintenance and minor features, but I'm spinning ideas at the moment. The nightly-build can be cloned and tested from github.

In my last week at the CRP Tudor in Luxembourg, I released the latest version 1.1 of the program.
For me the project is still interesting, but due to work and my studies I will not be able to commit as much time as I did in the last year. To allow continuation of the development for anybody who is interested I decided to move my development from a private SVN-Repository at my university to a public Development-Repository.

For a different project I already worked with GIT and I was pleasantly surprised - once branching is common for you, you don't want to go back to anything else. GitHub is a platform for project development and free to use for open-source projects. The cool thing about Git in general and GitHub in particular is the easy branching and forking. You can fork my project easily and while you develop in your own project clone, you can easily invite me to pull your changes back into my code. GitHub is like a social network for projects and everybody who is interested can clone and fork the project.

In the future I will run two branches, the master branch will be the stable version, which hopefully always works and will always run as good as possible. I will develop on the development branch incase me or somebody else wants to start new features.

ImageFlow-Repository at Github

This is the new stable release of the application. It introduces some new features. Among them is Grouping of units, new data types to use within the workflow and Stack-support.

Description

ImageFlow is a node-based Macro-Editing interface for ImageJ.

More details in the information sheet.

Documentation on the Unit-Element XML-Specification.
The new version brought agaimupdates to the specification. The changes are noted in the document.

Installation

Requires: Java Runtime Environment 1.5
Tested on Windows XP, Ubuntu and Mac OS X 10.4

Run as standalone application:

1. Download the archive


2. Extract into a directory on your hard drive


3. Launch the Imageflow_.jar

Run as ImageJ-Plugin:

1. Download the archive and extract the included Imageflow-folder.


2. Navigate to the plugins-directory of your ImageJ-installation


3. Copy the Imageflow-folder into ImageJ's plugin-folder


4. Restart ImageJ and a new menu-item for Imageflow appears in the Plugins-Menu.

Download

Download Imageflow 1.1 for Windows, Linux and Mac OSX

Download Imageflow 1.1 Java Sources

As always, I appreciate bugreports or other feedback.

The work at Tudor has been productive. We added several new features in the last couple of weeks. We aren't finished yet, but we like to get a new version out before our last weeks are beginning.

Our main focus has been on make workflows more flexible and allowing more ways of prototyping. Up untill now only image-data could be processed in the workflow. This has been extend to other datatypes and so you can also do calculations within the flow. The basics are implemented and we added the most common units. this will be included for testing in the next version.

Version 1.1 should be regarded as unstable. We tested the last few days and tried to find as many bugs as possible, but since there were some bigger changes internally, We suggest some caution. Workflows from version 1.0 should be compatible.

Also new are some features regarding the handling of workflows. It is now possible to group selected units into one element. These groups can be edited and degrouped later. The workflow is still fully functional, although the presentation is much simplified.

More soon.

This is the first version of Imageflow I regard as stable. Frido and me tried to test it thoroughly over the past week and hopefully we missed nothing. On the other hand, if we do missed something, we have the best reasons to continue development.

Description

ImageFlow is a node-based Macro-Editing interface for ImageJ.

More details in the information sheet.

Documentation on the Unit-Element XML-Specification.
The new version brought some slight updates to the specification. The changes are noted in the document.

Installation

Requires: Java Runtime Environment 1.5
Tested on Windows XP, Ubuntu and Mac OS X 10.4

Run as standalone application:

1. Download the archive


2. Extract into a directory on your harddrive


3. Launch the Imageflow_.jar

Run as ImageJ-Plugin:

1. Download the archive and extract the included Imageflow-folder.


2. Navigate to the plugins-directory of your ImageJ-installation


3. Copy the Imageflow-folder into ImageJ's plugin-folder


4. Restart ImageJ and a new menu-item for Imageflow appears in the Plugins-Menu.

Download

Download Imageflow 1.0 for Windows, Linux and Mac OSX

Download Imageflow 1.0 Java Sources

As always, I appreciate bugreports or other feedback, especially regarding the direction this tool should take.

Credits for this go to Johannes at Tudor.

Obviously I'm using ImageJ as the basis for my programm. I have been looking for a way to start ImageJ headless, having an instance without the WindowFrame, which starts up automatically when creating a new ImageJ-instance. I asked a few colleagues here at Tudor and we dived into the topic. In it's constructor ImageJ has a call for the show()-method, which instantly displays the ImageJ-window. show() has been deprecated for 2 Java-versions and so we thought, well let's override it locally. We empty the show()-method and on testing, nothing happened. Nothing like in "nothing showed up". We dived deeper. We couldn't use setVisible(boolean) the replacement of show() anymore, looked in the java-source only to find, that setVisible() does nothing more than using the old deprecated methods of show(). Nice one!

So we hacked a boolean-variable, which defines outside the class, whether or not the show should do something or not. Here is the code. Enjoy!

class StartIJheadless {

static boolean hide = true;

public static void main(String[] args) throws Exception {

ImageJ ij = new ImageJ() {

@Override
public void show() {
if (!hide)
super.show();
}

};
// ImageJ starts without GUI

hide= false;
ij.setVisible(true);
// it shows up
}
}

I posted a request in the mailinglist of ImageJ to introduce a clean way to start IJ headless. This can't be the solution.

I had an interesting talk yesterday, with an interesting question. What's the direction?
Honestly that's a very good question. I have the feeling ImageFlow is a very nice tool, but I don't really know how it is used and therefore in which direction I should concentrate.

Speaking with Andreas and Frido here at Tudor we have many ideas, hopefully one for a proper direction as well.

So working on the programm for a week now, we get quite a few things done for the first stable version.

I added a few new Unitelements. for example for merging RGB-channels, for FFT, Saving and more. Adding new units is kind of a in-between task, if I get bored, I add a new one.

Alot of work has been spent fixing the algorithm for sorting the units to generate the final macro. I introduced Frido to the topic and explaining the algorithm helped finding a few issues. Rubber duck debugging works.

Frido also fixed a problem with the GUI. You can now actually resize the sidepane on the left.
Also new is to display a grid on the workspace and to align all units to this grid. To sum up the obvious new features is to collaps units to take up less space on the workspace.



Here is a screenshot, work continues with debugging.

I have a few news.

I arrived in Luxembourg today to start a 4 months internship at the Research Institute Henri Tudor. I'll work here for the next 4 months. My work will be on some of the projects in progress here, as well as continued development of Imageflow. I repeat, after finishing my thesis about the programm, I can continue it's development and I'll be joined by Friedrich Maiwald, a colleague of mine from Berlin. So twice the fun.

During the week we will brainstorm for the next version and lay out a few milestones. First task will certainly be to get the first stable version based on the march-beta out. There are still a few quirks I'd like to address, but I don't want to be postpone anymore. So hopefully the new version and the related sources will be out soon.

I will write more often now.

I have to do a small status report. I finished writing my Bachelor thesis, had my oral exam on monday and got my degree. Everything went perfect and I'm relieved everything went alright. Understandably, I had to get away from it for a couple of days and I began to work on the changes for version 1.0 just this weekend. I found a couple of bugs and I got a few reports I will fix for the first full release. Part of the changes will be to see how I can get the sourcse to a point that can be released. I'm not saying they are a mess at the moment, but the dependencies between my application and VisualAp could need some cleanup and the project-structure for compilation has to be checked.

Since october I have been working on the project. As you could follow in the blog, at time more active than others, but the progress is not the topic. I pritty much worked on my own and only consulted with my Professor every now and then. I presented the application to colleagues and friends and got a bit feedback, but I didn't really talk to the ImageJ-community about it, yet. It makes me even happier that people write me and compliment me on the program. It's beta, it's buggy, but I appreciate your feedback. Gives me great joy and motivation to continue to work on the first stable release.

(Even though I should be writing my thesis now )

The first version is released. This includes basically all functions of version 1, but is not thoroughly tested and therefore taken as non-stabile.

Description

ImageFlow is a node-based Macro-Editing interface for ImageJ.

More details in the information sheet.

Documentation on the Unit-Element XML-Specification.

Installation

Requires: Java Runtime Environment 1.5
Tested on Windows XP, Ubuntu and Mac OS X 10.4

Run as standalone application:

1. Download the archive


2. Extract into a directory on your harddrive


3. Launch the Imageflow_.jar

Run as ImageJ-Plugin:

1. Download the archive


2. Navigate to the plugins-directory of your ImageJ-installation


3. Create a subfolder called "ImageFlow"


4. Extract the archive into this folder.


5. Restart ImageJ and a new menu-item for Imageflow appears in the Plugins-Menu.

Download

Download Imageflow-binaries

Sources will be available for the final version or on request.

I appreciate bugreports or other kinds of feedback.

I've been working the past 2 weeks and had some good progress. Here are 2 more screenshots. One with a working graph, second one displaying a faulty one with some error messages cause by incompatible image types.





I plan to release the first beta very soon.

Here is a screenshot of the current UI:



The tree on the left lists the available units. It doesn't work yet, but you will be able to drag'n drop them right on the workflow. Most functions are available in the menus at the moment.

I'm back on track slowly working through the remaining Todo-List.

I worked on the bitdepth-checks today, coming to a conclusion which brings a rather bad feel in the stomach. The way I planed to do it, doesn't work out.

So what is the task at hand. ImageJ supports sevral different ImageTypes: RGB Color, 8-bit greyscale, 16-bit greyscale, 32-bit greyscale … Most ImageJ-Filters allow to process all of them, but some only allow one or more types. Connecting two non-compatible units at best gives an proper error as soon as you run the macro, but worse, can give you no good clue what's actually wrong. So I wanted to check durin graph-building that the correct imagetypes are ensured.

My discovered problem is now, that during the time of building the graph we don't actually know the Type the image will have when it is processed by ImageJ. Each unit knows which inputs it allows to process, but not what is actually passed threw. So a unit who DOES_ALL can connect to a unit which only allows 16bit, because DOES_ALL might pass 16bit, we don't know.
I could try to work through the graph to find, which image type is input at the sources. But the source itself also just returns DOES_ALL. It would require to actually check the input file to get its imagebitdepth. This takes alot more attention that thought. :/
Atm I begin to consider it rather nice-to-have. The basic check is included, the more sophisticated will need more time.