Consider macro example instead of Java code for batch processing in README

[imagejan]

The "Java macro" example in the README is a poor choice because of following reasons:

• It's not a "macro" in ImageJ speak, but a Java script. The term "macro" refers to ImageJ's own macro language.
• In a standard Fiji, the code cannot be compiled from the script editor, because Fiji bundles a JRE instead of a JDK (see e.g. this forum discussion for details). You need to point ImageJ to your system Java installation to be able to run the example code.
• Macros are much more accessible to new users compared to typed Java code.
• The example code makes multiple use of IJ.getImage(), thereby relying on the UI displaying an image. This won't work in headless mode and is therefore unsuitable for batch processing. The macro language, in contrast, supports a batch mode that works in headless environment.

I suggest to replace the code by a real macro, and supplement it with code in a supported scripting language such as Groovy, to illustrate more advanced interaction with this plugin's API (if applicable).

I'll try to come up with an illustrative example when I find the time.

[wolny]

I've chosen vanilla Java instead of the ImageJ's macro language, cause I couldn't make string interpolations work in the macro, e.g.:

name = ...
for (i=0; i<list.length; i++) {
  run("Command", "param1=$sname param2=output$i"
}

just won't work and I wanted to avoid ugly string concatenations.

[imagejan]

run("Command", "param1=$sname param2=output$i"

This works (see also the docs):

param1=&name

(mind the & instead of $) but something like output$i will not work in macros.

String concatenations are a common thing in macros, why do risk to lose the largest part of ImageJ users, just to have "nice-looking" Java code?

While I share some of the concerns about the IJ macro language, I'd suggest to include a Groovy example. Java is really the worst choice IMHO, when talking about "macro"-like batch processing without an IDE.

[wolny]

String concatenations are a common thing in macros, why do risk to lose the largest part of ImageJ users, just to have "nice-looking" Java code?

totally agree with the above. It should not be hard to rewrite the Java script example with the macro language and Groovy so we should do just that. Thanks