You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Right now, if an ImageJ module takes an image as input, it exposes that input to OMERO as a long called Image_ID. But the typical convention in OMERO clients is to use a parameter called IDs that is a string, formatted as a comma-separated list of image IDs. We could support this in the ImageJ-OMERO bridge by exposing image inputs as string IDs rather than long Image_ID, and then having special handling of any IDs parameters. The ImageJ-OMERO ModuleAdapter would need to split the IDs into a list, then call the module in a loop with each downloaded image of those IDs.
This is a quite special case—it becomes more complicated if an ImageJ module (such as Image Calculator) takes more than one input image. In such cases, we probably cannot do clever looping like this. But supporting single-image inputs in a loop this way would fulfill 80+% of use cases in a more convenient way.
There is now a SciJava batch processor thanks to @imagejan. Perhaps it makes most sense to utilize this framework for supporting execution of SciJava modules across multiple OMERO images?
On the batch-processor side, we could create a BatchInputProcessor interface and then an OMEROImgBatchInputProcessor (or some better name) that takes an IDs string and provides a list of Img objects (or whatever the module needs as input, as long as we can convert it) for a module to run (with batch-processor taking care of running the actual loop).
I was considering such an extensible plugin framework for both batch inputs and batch outputs and would like to hear opinions if that makes sense. See also scijava/batch-processor#14.
Right now, if an ImageJ module takes an image as input, it exposes that input to OMERO as a long called
Image_ID
. But the typical convention in OMERO clients is to use a parameter calledIDs
that is a string, formatted as a comma-separated list of image IDs. We could support this in the ImageJ-OMERO bridge by exposing image inputs as stringIDs
rather than longImage_ID
, and then having special handling of anyIDs
parameters. The ImageJ-OMEROModuleAdapter
would need to split theIDs
into a list, then call the module in a loop with each downloaded image of those IDs.This is a quite special case—it becomes more complicated if an ImageJ module (such as Image Calculator) takes more than one input image. In such cases, we probably cannot do clever looping like this. But supporting single-image inputs in a loop this way would fulfill 80+% of use cases in a more convenient way.
/cc @jburel
The text was updated successfully, but these errors were encountered: