ImageJ

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'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.