Support ImagePlus parameters

[hinerm]

The Manual Threshold... .js script creeps into the search results and its ImagePlus parameter doesn't map appropriately. This will have to be handled appropriately in conjunction with imagej/imagej-legacy#264

[ctrueden]

In general, we need to handle ImagePlus inputs and outputs. Users may write their own scripts that use this data structure, and will expect it to work with these scripts installed into their ImageJ2 environment. The PyImageJ project should handle them though, so making napari-imagej deal with them as well shouldn't be extra effort? I hope. Just need to figure out why the type mapping here is wrong.

[gselzer]

Just need to figure out why the type mapping here is wrong.

It is because it is commented out 😜

This fix may be as simple as uncommenting these lines.

[ctrueden]

This fix may be as simple as uncommenting these lines.

I think it needs to be conditional on the original ImageJ being present on the classpath, though. You don't want napari-imagej to crash when the legacy layer is absent.

[gselzer]

Yes, we should surround that import with a try/except

[gselzer]

Okay, so here's the current state of the major players in this PR.

• We can get an ImagePlus from napari Image layers. For that reason, you won't get any errors when you run ManualThreshold.js.
• The ManualThreshold command doesn't do anything in napari-imagej, because it alters the (original ImageJ) color table via ImageProcessor.setThreshold. The color table changes do not transfer into napari-imagej - I'm guessing they cannot be synced into the Dataset via the legacy image map...

What is the step forward here? Is there anything left to do as far as napari-imagej goes? Should we file an issue in imagej-legacy to ensure that the color table changes are made?

[ctrueden]

Probably related: #138.