@ Parameter issue ImagePlus versus Dataset versus Img

Tags: #<Tag:0x00007fa307190580> #<Tag:0x00007fa307190440> #<Tag:0x00007fa307190300>


Hey guys,

I’m experiencing some weird behaviour when working with the @ Parameter stuff from jython scripts. I have some scripts generating ImagePlusses and some others creating Imgs. Now, I would like to combine these images in another script and get the images as parameters; ideally as Datasets. The pulldowns in the dialog are build in a weird way. This is my minimal code example for creating these images:

#@UIService ui
#@OpService ops

from ij.gui import NewImage
from net.imglib2.util import Intervals

imp = NewImage.createByteImage("test1", 100, 100, 10, NewImage.FILL_BLACK);

img = ops.create().img(Intervals.createMinSize([0,0,0,100,100,10]));
ui.show("test2", img);

This script works nicely and afterwards two images are shown: test1 and test2.

If I write and run this tiny script

#@Dataset data1
#@Dataset data2

print("Hello world");

the popping up dialog looks like this:

Thus, I cannot select image test2! This is a pitty as I actually need it as Dataset :frowning:

Then, I wrote a script like this

#@ImagePlus imp1
#@ImagePlus imp2

print("Hello world");

which opens this dialog and pulldown:

This pulldown contains test2. But again, I need the input images as Datasets.

If I write that:

#@Img data1
#@Img data2

print("Hello world");

the dialog looks like this:

Last but not least, mixed inputs:

#@ImagePlus imp1
#@Dataset data2
#@Img img3

print("Hello world");

and the corresponding dialog:

Note: The dialog shows only one pulldown!

Actually, I would be happy if I could select the images using the Dataset-parameter-way-of life. I just posted the other examples for completeness. Is there a way of showing an img as a Dataset so that it appears in the pulldowns?

Any hint would be helpful.


When is DatasetService "updated"? and getting a list of 'Dataset'
Changing IJ1 image type -> IJ2 command keeps the old image
What is the best way to get an open image in a plugin?
Command with 2 Images

Great questions, @haesleinhuepf. Thanks for the minimal examples. I would love to dig in to these issues and fix related bugs, but this week I am scrambling to finish an urgent project, and next week I’m on holiday. So I fear any investigation on my side must wait till at least August. :disappointed:

As always, anyone in the community who wants to explore it in the meantime is more than welcome to do so.

Here are a couple of comments, off the top of my head:

  • There is a lot of magic going on to translate these things back and forth in ImageJ Legacy. The magic is known to be incomplete in some circumstances, so it is not too surprising that there are issues when you really exercise it like this—e.g. by mixing and matching.

  • There is a known (to me) issue of the dropdowns showing weird stuff like stringified objects (e.g. your plugin:class ... entries) even in simple cases. I would love to fix this annoying problem, but have not had time yet. Someone should probably file a GitHub issue for it because I do not think there is one. Actually, why not file this whole thread into an issue in imagej-legacy, since it is really a big ol’ bug?

  • The reason you cannot mix and match is probably related to the fact that the “single input preprocessor” logic works by type. So e.g. if you have a single Dataset, it grabs the active image. And if you have a single ImagePlus, it grabs the active image. If you have one of each, the current code treats that as two separate things, and so each input gets filled with that same active image! Not ideal! We’ll have to think about the best way of making these preprocessors a little broader, so there is only one single “active image preprocessor” rather than multiple. This should be easily doable by leaning on the ConvertService. If anyone is ambitious/brave enough to dig in to that, you’ll need to explore the InputHarvester subsystem including the org.scijava.widget package and how the DefaultWidgetModel caches converted inputs. See e.g. AbstractInputHarvester::getObjects and ConvertService::getCompatibleInputs.

Sorry I don’t have a better/faster answer for you, Robert. But this stuff is crucial to have working well, so please keep pinging me if you are stuck, I’m unresponsive, etc.

Changing IJ1 image type -> IJ2 command keeps the old image

Thanks for the feedback, @ctrueden !

I just filed the issue on github:

Furthermore, the very last example with Img, ImagePlus and Dataset input parameters is a bit artificial. I would definitely not focus on fixing that one. But it may be a hint on how to fix the weird content of pulldowns.


I have stumbled over a similar - if not the same - issue with @milkyklim with ImagePlus parameters.

As predicted by @ctrueden, my debugging session has lead me to AbstractConvertService.getCompatibleInputs(): if you use SCIFIO to open an image (i.e. create a Dataset), there are actually three Converters that could convert something to ImagePlus: ImageTitleToImagePlusConverter, StringToImagePlusConverter, and DatasetToImagePlusConverter. The problem seems to be, that all three converters are adding Objects to the list of compatible inputs, where different Objects (ImageTitle, String, Dataset) are referring to the same image:


EDIT: There is also ImageDisplayToImagePlusConverter and ImageDisplay to add to my previous ramblings.


Hey guys,

after the recent Fiji update, the situation on the issue posted above changed a bit. To follow up on our discussion, I’m posting the scripts from above again together with updated screenshots. Just a reminder: there are two images open: An ImagePlus (test1) and an Img (test2). Goal is to fix the entries inside the Dataset-selection widgets

#@Dataset data1
#@Dataset data2

print("Hello world"); 


#@ImagePlus imp1
#@ImagePlus imp2

print("Hello world");


#@ImagePlus imp1
#@Dataset data2
#@Img img3

print("Hello world");




Hey guys,

I’m having another issue with these widgets: Fiji freezes completely and almost stops the operating system from responding, when doing the following:

Run this script:

from ij.gui import NewImage
from ij.plugin import Duplicator

# generate a 500 MB image
imp1 = NewImage.createByteImage("test1", 1000, 1000, 500, NewImage.FILL_BLACK);

# duplicate first slice
imp2 = Duplicator().run(imp1, 1, 1)

Afterwards, Fiji reserves almost 2 GB of random access memory. Then, run this script:

#@Img img1
#@Img img2

print("Hello world")

This dialog shows up:

Fiji freezes after clicking Ok. While freezing, memory increases steadily (I killed the app after 9 GB were reached) and processor usage goes up to 99%. It looks like an endless loop allocating memory. It is reproducible on several machines running on Windows 10, 64 bit with a freshly downloaded Fiji/ImageJ 2.0.0-rc-64/1.51s Java 1.8.0_66 [64 bit] without any special update sites activated.


@haesleinhuepf Please see these links to investigate the problem:


Please also see this issue:

This should actually be in imagej-legacy, sorry for having reported this at the wrong place at that time…


It suprises me that this bug was reported half year ago, because before the December update, all my plugins were working (most of them take several Imgs as input). Just recently, Fiji started hanging,…


@haesleinhuepf Did you figure out why?


Hi all

I’m cross posting from my other thread, as I believe I’m experiencing similar issues.

Additional Note: I went back and looked at scripts that were previously working such as Find_Template.py. With this script I now get ‘A ImgPlus is required but none exist’ message and the script does not run.

Here I wrote a command that takes two 3D images as input.

  1. If I use Img as the parameter type the GUI freezes when I attempt to select the image.
  2. If I use ImgPlus as the parameter type a message appears, complaining that no ImgPlus are open when I run the command.
  3. If I use Dataset as the input it works.

I wonder if the issue is related to this one. In this case the Richardson Lucy Op froze and crashed imagej when run through the op finder. I looked into it a bit, and it seemed it was a general problem that occurred when using a 3D image as input to any op. 2D images worked fine. (Note: My most recent experiments show the problem happening with both 2D and 3D… perhaps I was mistaken that the problem only happened with 3D images.)