Posted by
dscho on
Jun 12, 2014; 2:03pm
URL: http://imagej.273.s1.nabble.com/Headless-ImageJ2-rc2-Analyze-Particles-returns-no-result-tp5008127p5008159.html
Hi Paul,
On Thu, 12 Jun 2014, Paul van Schayck wrote:
> On Thu, Jun 12, 2014 at 1:22 AM, Johannes Schindelin
> <
[hidden email]> wrote:
> > Thank you for that reproducer script, it really saved me *a lot* of time.
> >
> > What it uncovered, however, are two problems, not one. That's why it
> > took so long: in headless mode, we would not register legacy images
> > properly, and also -- a really, really longstanding bug! -- the
> > headless generic dialog never parsed numbers properly. It always
> > returned 0. Therefore, your circularity filter was converted into
> > circularity=0.0-0.0.
> >
> > I fear this bug goes way back into our first headless support days in
> > ImageJA, so it is really embarrassing, but all the better that you
> > uncovered it!
> >
> > Unfortunately, I ran out of time today to clean up the fixes and
> > upload new file versions, but I promise to do that tomorrow.
>
> I figured it was a longer standing bug (and should have mentioned
> that) as I could only get the particle analyzer headless working on
> rather old version of Fiji.
Oh, that is interesting. So maybe at the time we started implementing the
headless hack that *kind of* replaced the GenericDialog with a purely
headless one in headless mode, there were no non-GUI methods in
GenericDialog? I will have to investigate when such functions, including
the parseDouble() one that was the culprit in your case, entered the fray.
This will probably uncover quite a few troubling bugs... please bear with
me, I want to fix this properly, rather than papering over the issue with
a workaround that causes even more problems in the long run [*1*].
> I'll keep an eye on Jenkins and Github for the fixes.
Hopefully this is not quite necessary. I try to follow up on mails when I
fixed the described problem... ;-)
> I'm also trying to rewrite the macro to js, still struggling a bit with
> that, should the bug also be visible there?
Yes. Both problems (that the image was not properly registered with ImageJ
1.x as well as the 0 particles found problem caused by the parseDouble()
method being incorrect in headless mode) would persist.
> Regarding the SCIFIO file opening. Your fix fixed the
> NullPointerException. However, now when running with SCIFIO enabled the
> following error is shown "There are no images open.". This regardless of
> whether I run headless or not, but only occurs when passing the macro
> through "-macro" as it does not happen when running from the script
> editor. Also adding a wait(4000); fixes the problem.
Yes, I think that I have a proper fix for that [*2*], but I still have to
verify that it does not cause other problems, add a unit test to guarantee
that the same bug does not reoccur, and then merge the topic branch. I
just ran out of time yesterday night, but I will work on this directly
after the first round of emails of the day.
> I fully agree on making SCIFIO default, I was very surprised when I
> first discovered a few months a go it was not implemented like this yet.
> It will add a lot of nice features.
Yes. I am rather proud of the system myself, having had a small part in
devising the technique we use. You could call it "HandleExtraFileTypes
Done Right", basically learning from years of experience with
HandleExtraFileTypes:
- it is truly extensible, i.e. different third and fourth parties can
*both* extend the mechanism; there is not a single class that you have
to modify in order to add your reader/writer, and if two parties
try to modify it, only one version wins. The other readers/writers
fall unsupported. This is particularly surprising when the overridden
HandleExtraFileTypes.class file is stuck into a plugin's .jar file.
- SCIFIO is called *first*, before letting ImageJ try to open the image,
i.e. it allows overriding the default implementation that us ImageJ
developers might have made too limited,
- since SCIFIO's plugin concept is based on SciJava's, and hence the
SCIFIO plugins are typed strongly, it is much easier to get SCIFIO
readers and writers right than it is to get ImageJ 1.x plugins right to
do the same.
A quick search for reader plugins failing to extend ImagePlus or to
interpret a non-empty arg as path (essentially breaking batch mode
operations with HandleExtraFileTypes) may demonstrate what I mean.
Please understand that I do not blame any of the authors of those
plugins: I myself was really surprised when I learned *years* after
writing the initial version of the Amira file format reader that you
should not call "imp.show();" at the end of the run() method, but
instead make the plugin class "extend ImagePlus" and then call
"setImage(imp);" at the end of the run() method.
The best thing about it, however, is how flexible SCIFIO is. By making it
a software library in its own right, SCIFIO can concentrate on its core
strength, and offer it to all users, including non-ImageJ ones. I have
experimental code that allows C++ programs to use SCIFIO, *without* even
the need for a Java Virtual Machine!
Of course, we have to stabilize the SCIFIO support first. But we're well
underway in that project, with outstanding help from the community,
including you!
> Regarding the command line options. I'm interested in running in true
> headless mode making -batch not directly interesting. So, if I
> understand correctly, that while "-macro" is a ImageJ1 option it is
> also the preferred way of starting the new ImageJ2 scripts (in js,
> bsh, etc). And how exactly does this all relate to the "--ij1" and
> "--ij2" flags.
Actually, my preferred way to run scripts is to call
ImageJ-<platform> script.bsh
or
ImageJ-<platform> script.js
directly. This will not spin up a context or for that matter, ImageJ, for
you, but makes it possible to use ImageJ truly as a library. You would
probably want to start up a context anyway, like this:
importClass(Packages.net.imagej.ImageJ);
ij = ImageJ();
ij.command().run(...);
We might want to change this in the near future, though, because the
SciJava scripting framework -- which puts all scripting languages into a
common, consistent shape -- is just about ready to be used by the ImageJ
launcher. If you are interested in that project, let's just add a ticket
on GitHub which you can follow to keep you updated automatically.
Ciao,
Johannes
Footnote *1*: I have a workaround, but this was only put into the code on
a topic branch, intended to identify the bug, not to fix it:
https://github.com/imagej/ij1-patcher/compare/master...headless-dialogFootnote *2*: the affected code lives in the imagej-legacy component (i.e.
the library that is supposed to leverage the extension points inserted by
ij1-patcher that lets ImageJ2 truly extend ImageJ 1.x):
https://github.com/imagej/imagej-legacy/compare/master...batch-mode-opener--
ImageJ mailing list:
http://imagej.nih.gov/ij/list.html