Command line support : what are your needs ?

[Stephane]

Icy currently has very limited command line support, here is a description of the supported parameters :

"--headless" or "-hl" to force Icy to start in headless mode (no GUI).
"--execute" or "-x" followed by the plugin class name you want to execute (for instance "plugins.kernel.importer.LociImporter") and the path of an image to open so if a plugin use the active image by default it will be able to process it.

Example (with windows path style) :
icy.exe -hl -x plugins.filter.convolve.Convolve2D "D:\images\myImage.tiff"

The problem is that you have to design the plugin so it can support to work from command line.
That means it should be able to do the process on the current active sequence from the default constructor and that is quite limiting as it can't receive others parameters.

One idea is to store the command line arguments at start so plugin can access it with a static method as getCommandLineArgs() (or getCommandLinePluginArgs() to retrieve only parameters entered after the plugin).
Still that would be more a "workaround" as the solution is not very elegant.
We could also looks for a specific constructor for the plugin as new Plugin(String[] args) but i believe that is not really better...

If you have any specific requests or suggestions about the command line support, that is the good topic :)
I guess there is many cases which don't fit with the solution here so we have to think about them and try to make most of people happy ;)

- Stephane

[Curtis Rueden]

Hi Stephane,

> If you have any specific requests or suggestions about the command

> line support, that is the good topic :)

This is an area where ImageJ2 has been quite focused. I would like to see ImageJ & Icy become closer together, with respect to Icy consuming ImageJ2 modules. These take the form of Commands (Java code) and scripts in various JVM scripting languages. The entire ImageJ2 module infrastructure is designed to make writing headless functionality easy, and to be easily consumed by other applications such as Icy, KNIME, OMERO, etc.

The "WorkingWithModules" tutorials explains in more technical detail:

https://github.com/imagej/imagej-tutorials/blob/master/working-with-modules/src/main/java/WorkingWithModules.java

But essentially, the idea is that if chunks of functionality can be implemented within the ImageJ2 module framework, and executed via the beautiful Icy interface, everyone wins because Icy becomes more powerful and those pieces of functionality are usable headless from the command line.

I'm happy to discuss further if there is interest on your end.

Regards,

Curtis

--
You received this message because you are subscribed to the Google Groups "Icy imaging" group.
To unsubscribe from this group and stop receiving emails from it, send an email to icy-software...@googlegroups.com.
To post to this group, send email to icy-so...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/icy-software/578132e1-6ddd-4652-a660-581c8c9afe69%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Stephane]

Hi Curtis,

Sorry for not replying any sooner. I've got a look on the module system in ImageJ2 and it is similar to how we are working with protocols / graphics programming stuff. The idea is that you have formatted inputs and outputs for your modules so we know how feed them and how to get the result. What is nice is that you implemented that from rock in the Module sub system where we pass by Block interface which is an extra piece in Icy Plugin system even if many plugins tend to use them.
Still how do you see communication between Icy and IJ2 modules ? I guess IJ2 modules use the IJ2 API and so Icy should be able to load all the IJ2 classes.

Best,

- Stephane

[Curtis Rueden]

Hi Stephane,

> Still how do you see communication between Icy and IJ2 modules ? I

> guess IJ2 modules use the IJ2 API and so Icy should be able to load

> all the IJ2 classes.

At a high level, it is similar to how the KNIME Image Processing nodes do it, or how Alida does it, or how CellProfiler does it: map Icy's typed input/output system to ImageJ2's via some bidirectional adapter mechanism. The toughest part is adapting the more complex data structures (such as images) back and forth. But the good news is that ImgLib2 is general enough that you will almost certainly be able to create a wrapper for Icy images that implements the relevant ImgLib2 interfaces. E.g., the imglib-ij project maps between ImageJ1 and ImgLib2 data structures [1]. The more stuff you can wrap by reference that way, the less expensive (in both time and memory) conversion must occur. The Icy extension that provides ImageJ2 support would simply declare ImageJ2 as a dependency, just the same as any other third party dependency.

I am currently at a hackathon in Konstanz, where we are developing the first version of imagej-ops: a framework for reusable image processing algorithms [2]. The awesome thing is that every "op" is an ImageJ module, so if Icy had support for ImageJ2 modules, it would automatically gain the use of the rapidly expanding collection of ops [3]. And all the ops are designed to be used headless, of course. :-)

Regards,

Curtis

[1] https://github.com/imglib/imglib-ij/blob/imglib2-ij-2.0.0-beta-25/src/main/java/net/imglib2/img/ImagePlusAdapter.java#L69

[2] https://github.com/imagej/imagej-ops/

[3] https://github.com/imagej/imagej-ops/blob/fc8662317cb83264081efb23814cc32df24c15f4/operations.txt

To view this discussion on the web visit https://groups.google.com/d/msgid/icy-software/dada680d-efa7-451e-99b7-c1e8da171c26%40googlegroups.com.