FMI KNIME Plugins version 0.19.0.202104201635 introduces imglib2 dependency issue

[charismatic-claire]

Suppose you created a segmentation using the Image Processing environment in KNIME. You can extract all the segments from your segmentation and get a list of bitmasks. Wouldn't it be great to convert this bitmask representation of the segments to a well-known text (*.wkt) representation. Why? Because it,s more universal.

And why not go the other way round too? Suppose you have an image and a list of segments in well-known text (*.wkt) format. It should be possible to convert those to bitmasks that can be used to assemble an image segmentation using KNIME's GroupBy node.

Here is the corresponding thread in the KNIME forum: Convert Well-Known Text (WKT) To Labeling

[charismatic-claire]

Here is the corresponding branch on my fork on GitHub:
https://github.com/charismatic-claire/fmi-ij2-plugins/tree/issue-13-wkt-bitmask

[charismatic-claire]

@imagejan I think there is a little problem with the merge of this pull request: Create plug-ins to convert well-known text to bitmasks and vice versa #14.

I installed a fresh copy of KNIME AP 4.3.2 and installed the following extensions as you normally would:

• KNIME Image Processing, 1.8.3.202103170902, org.knime.knip.feature.feature.group, University of Konstanz / KNIME
• KNIME Image Processing - ImageJ Integration (Beta), 0.11.7.v202007071306, org.knime.knip.imagej.feature.feature.group, KNIME / LOCI
• FMI KNIME Plugins, 0.19.0.202104201635, ch.fmi.knime.plugins.feature.feature.group, Friedrich Miescher Institute for Biomedical Research, Basel

I wanted to test the newly added "Well-Known Text (WKT) to 2D Binary Mask" node. Executing it, I ran into the following issue:

ERROR    KNIME-Worker-8-Well-Known Text (WKT) to 2D Binary Mask 0:3 Node         Execute failed: net.imglib2.img.ImgView.wrap(Lnet/imglib2/RandomAccessibleInterval;)Lnet/imglib2/img/Img;
java.lang.NoSuchMethodError: net.imglib2.img.ImgView.wrap(Lnet/imglib2/RandomAccessibleInterval;)Lnet/imglib2/img/Img;
        at ch.fmi.wkt.WellKnownTextToBitmask.run(WellKnownTextToBitmask.java:105)
        at org.scijava.command.CommandModule.run(CommandModule.java:199)
        at org.scijava.module.ModuleRunner.run(ModuleRunner.java:168)
        at org.knime.knip.imagej2.core.node.AbstractIJCellFactory.executeRowModule(AbstractIJCellFactory.java:228)
        at org.knime.knip.imagej2.core.node.StandardIJCellFactory.getCells(StandardIJCellFactory.java:134)
        at org.knime.core.data.container.RearrangeColumnsTable.calcNewCellsForRow(RearrangeColumnsTable.java:568)
        at org.knime.core.data.container.RearrangeColumnsTable.calcNewColsSynchronously(RearrangeColumnsTable.java:488)
        at org.knime.core.data.container.RearrangeColumnsTable.create(RearrangeColumnsTable.java:405)
        at org.knime.core.node.ExecutionContext.createColumnRearrangeTable(ExecutionContext.java:430)
        at org.knime.knip.imagej2.core.node.StandardIJNodeModel.createResultTable(StandardIJNodeModel.java:197)
        at org.knime.knip.imagej2.core.node.AbstractIJNodeModel.execute(AbstractIJNodeModel.java:265)
        at org.knime.core.node.NodeModel.execute(NodeModel.java:747)
        at org.knime.core.node.NodeModel.executeModel(NodeModel.java:576)
        at org.knime.core.node.Node.invokeFullyNodeModelExecute(Node.java:1245)
        at org.knime.core.node.Node.execute(Node.java:1025)
        at org.knime.core.node.workflow.NativeNodeContainer.performExecuteNode(NativeNodeContainer.java:558)
        at org.knime.core.node.exec.LocalNodeExecutionJob.mainExecute(LocalNodeExecutionJob.java:95)
        at org.knime.core.node.workflow.NodeExecutionJob.internalRun(NodeExecutionJob.java:201)
        at org.knime.core.node.workflow.NodeExecutionJob.run(NodeExecutionJob.java:117)
        at org.knime.core.util.ThreadUtils$RunnableWithContextImpl.runWithContext(ThreadUtils.java:334)
        at org.knime.core.util.ThreadUtils$RunnableWithContext.run(ThreadUtils.java:210)
        at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
        at java.util.concurrent.FutureTask.run(FutureTask.java:266)
        at org.knime.core.util.ThreadPool$MyFuture.run(ThreadPool.java:123)
        at org.knime.core.util.ThreadPool$Worker.run(ThreadPool.java:246) 

As far as I can see, this is the line of code in ch.fmi.wkt.WellKnownTextToBitmask that is causing the issue:

Img<BitType> image = ImgView.wrap(interval);

I noticed that this is different from what I initially contributed:

Img<BitType> image = new ImgView<>(interval, new ArrayImgFactory<>());

So what is the problem? The version of imglib2 is to old to recognize the ImgView.wrap() method? How can we fix this?

[imagejan]

@charismatic-claire thanks for letting me know, and sorry for this!

I had changed the call to ImgView.wrap because the other one is deprecated in newer versions of ImgLib2, but apparently we have a dependency version skew between the dependencies defined in pom-scijava-30.0.0 (which fmi-ij2-plugins use as a parent POM) and the ImgLib2 bundle of the KNIME Image Processing (KNIP) extension. I have to check which version of imglib2 is used in the latest KNIP.

If it can't be updated in KNIP relatively shortly, I'll re-introduce your original, backwards-compatible call.

[imagejan]

@charismatic-claire sorry for the delay, I released a new version just now:

FMI KNIME Plugins	0.19.1.202104271004	ch.fmi.knime.plugins.feature.feature.group

This includes https://github.com/fmi-faim/fmi-ij2-plugins/releases/tag/fmi-ij2-plugins-0.8.1 which fixes the compatibility with ImgLib2 version 5.8.0 that's shipped currently with the KNIME ImageJ integration.

I quickly tested with a KNIME workflow going from WKT to bitmask and back, and didn't see any issues 🎉 .

[charismatic-claire]

@imagejan, cool! Well so it might take a while until imglib2 can be updated within knip I take it? Since every knip extension depends on it, this isn't trivial, right? You don't wanna break something by carelessly updating it I suppose...

[imagejan]

@charismatic-claire yes, I simply assumed it might take a while until knime-ip/knip-externals#31 gets closed, as there's currently not much development on the knip side going on...

In theory, I assume we could just include a more recent imglib2 version in fmi-knime-update-site, but I don't want to ship too many custom dependencies via that site, but rather rely on the bundles defined in knip-externals as much as possible, to reduce the maintenance burden on our side.

Anyhow, introducing backwards compatibility to ImgLib2 5.8.0 wasn't too much of a hassle in this case 🙂.