Running an ops from imagej menu crashes



Dear All,

Running an ops from imagej menu crashes with an error of the type:

java.lang.ClassCastException: de.mpicbg.scf.InteractiveWatershed.HWatershed_Plugin cannot be cast to net.imagej.ops.OpEnvironment

The same error occurs from a IJ1 macro if not all the parameter are provided (even for parameter annotated with required=false )

At the same time running the same op from a script with an OpService works just great.

I could not find the corresponding issue on github but I’ve heard that there is a correction around in imagej-ops-0.38.1 . That would be great if it could be distributed to all as such bug really impact end user that work from the UI or with macro language. I am happy to file an issue if needed.



Which Op are you trying to run, and how exactly are you invoking it from the menu? As far as I know, ImageJ Ops are not accessible directly from the menu (yet).

It would certainly be helpful if you can post the code you’re using.

The following macro works as expected for me:

#@ String (required=false) text1
#@ Integer (required=false) value1

print (text1+value1);

If I leave text1 empty, it complains at the print statement with Undefined variable, but the input harvester doesn’t complain.


Hi @imagejan,

Thanks for the feedback. I have no problem with the script annotation these work great for me. I have built a custom op which is also visible in the menu thanks to annotation and noticed that it crashed when clicked started from the menu. The code is available there:

You can try it by downloading the update site SCF_MPI_CBG and the op is visible at the menu entry SCF>labeling>H_Watershed

to run it from a macro I use:

hMin = 20;
thresh = 100;
peakFlooding = 90;
run("H_Watershed", "impin="+getTitle()+" hmin="+hMin+" thresh="+thresh+" peakflooding="+peakFlooding);


Ah, now I see! Thanks for providing more detail :slight_smile:

Can you post the whole stack trace?

Maybe the Ops specialists (@ctrueden, @dietzc) can help out here?

Also, is there a reason why you make your command an Op and not just a simple Command (extending ContextCommand or DynamicCommand)? You can then still run it both from the menu and from scripts (via CommandService) but you don’t have to meet the additional criteria for Ops…


I use an op here because it is more convenient to run from the script editor ( result =…) and nothing pops up in the ui ). Also it is simple enough to be taught in scripting course for biologists. in that context CommandService requires more understanding of java which one would not have when starting to script. Also when I first made that op available it was working wonderfully from script, macro and menu which probably has been changing with the big June update of IJ/Fiji.

For the record, I discussed that issue with @ctrueden in June at Dresden Learnathon and the problem was already known and had a fix. I was hoping that poking a bit could help having that available fix available in an update soon. At the same time, I know that you guys are putting a lot of efforts in the development of ImageJ and I am sure there are very good reasons for it not to happen yet.

In any case, Here is the Full stack trace:

[ERROR] Module threw exception
java.lang.ClassCastException: de.mpicbg.scf.InteractiveWatershed.HWatershed_Plugin cannot be cast to net.imagej.ops.OpEnvironment
at net.imagej.ops.NamespacePreprocessor.assignNamespace(
at net.imagej.ops.NamespacePreprocessor.process(
at org.scijava.module.ModuleRunner.preProcess(
at org.scijava.thread.DefaultThreadService$
at java.util.concurrent.ThreadPoolExecutor.runWorker(
at java.util.concurrent.ThreadPoolExecutor$


This bug is fixed on imagej-ops master, but no new release has been cut yet. For the moment, you can download the latest snapshot build and replace your local imagej-ops JAR with that one.

I will try to do a release soon, maybe at the KNIME/Ops hackathon later this week or next. There is no “very good reason” for the delays except having too much on my plate, and not enough others working on the project these days.


Thanks for the feedback!

That is great news!

As for the lack of people working on the project, I’d be happy to give a hand. However, being more of an analyst with end user perspective than a hard core developer I’d love it if someone could point some areas where I could help. More generally, I believe many of us working with end users would be glad to help polishing IJ if provided with common directions.


Many apologies for the delay. I was too busy at the hackathon, but I have not forgotten about doing this release. I tried to do it just now, but the current imagej-ops master branch has test failures. I am investigating now, and will reply back once they are fixed and a release has been made.

What we need most are more developers working on core infrastructure. I think grant proposals are the way to go for that. Worry not: multiple collaborating institutions are pursuing it. :grin:

That said, image analysts are well poised to help in several different ways!

  • Improve the documentation at
  • Fix small/easy bugs you find in the code on GitHub
  • File issues on GitHub when things don’t work
  • Answer questions here on
  • Take responsibility for one or more Fiji components by adopting a team role:
    • Support - Respond to support requests on public channels such as this forum
    • Reviewer - Look over and approve GitHub pull requests when they come in for your component(s)
    • Debugger - Investigate and debug problems with your component(s) when they are reported
    • Developer - Add new features to your component(s) upon user request
    • Lead, Maintainer - Make decisions about when to cut new releases and make them available to end users

One great example (among many) is @Christian_Tischer with Correct_3D_Drift. I highlight this component in particular because it is actually a Python script—you don’t need to master the Java language to get involved with component development and maintenance.

One thing I want to emphasize is that it is very helpful to strive for centralized documentation and online resources. Creating your own tutorial in your own GitHub space is great, but much less visible and accessible than adding to the official ImageJ tutorials. Same thing with doing your own blog post, or external documentation on your web site, or running your own ImageJ workshop with your own workshop materials. Those things are all good, but much better is to contribute it to the appropriate central resource—e.g., the Presentations page of the ImageJ web site.