Questionable ops search results

[hinerm]

Here we have threshold.apply - I think this is mapping to this op whose parameters a) not images, I think?, as reported by the napari-imagej ui - and also if they were images they are not being represented properly in the widget.

If I actually try to run this I get an exception:

I'm not sure this how this Op would actually be runnable from napari-imagej. Are the search results already restricted to image-applicable results? and is this just a case of misinterpreting the params as images?

[gselzer]

Here we have threshold.apply - I think this is mapping to this op whose parameters a) not images, I think

I think it is actually this op. It's unfortunate that the OpSearcher does not have a Source button like the other modules do 😦

If I actually try to run this I get an exception:

Hmm, the traceback might help here. I know that conversion to RealTypes has not worked because Fiji did not know how to convert Numbers to RealTypes until recently. My guess is that the imagej-common is too old; we need imagej-common-0.35.0 to get the commits from imagej/imagej-common#82.

[gselzer]

Are the search results already restricted to image-applicable results?

The search results are completely unrestricted right now, although we may need to restrict them in the near future. (i.e. allow widgets requiring headful execution to only be searchable when ImageJ is not running headlessly).

[ctrueden]

we need imagej-common-0.35.0 to get the commits from imagej/imagej-common#82.

So, in the napari-imagej source, for the imagej.init endpoint, just add +net.imagej:imagej-common:0.35.0 for local testing. I'll keep working on getting ImageJ2 v2.6.0 out the door, but it will be a couple of weeks yet probably.

[ctrueden]

ImageJ2 2.9.0 includes imagej-common 0.35.0. Does it address this issue?

[gselzer]

Unfortunately, this is still broken, although for different reasons.

Assuming we're all up to date on our java/python dependencies, we still have trouble:

 java.lang.ClassCastException: net.imglib2.type.numeric.integer.IntType cannot be cast to net.imglib2.type.numeric.integer.UnsignedByteType
	at net.imglib2.type.numeric.integer.UnsignedByteType.compareTo(UnsignedByteType.java:50)
	at net.imagej.ops.threshold.apply.ApplyThresholdComparable.compute(ApplyThresholdComparable.java:56)
	at net.imagej.ops.threshold.apply.ApplyThresholdComparable.compute(ApplyThresholdComparable.java:46)
	at net.imagej.ops.special.computer.BinaryComputerOp.compute(BinaryComputerOp.java:93)
	at net.imagej.ops.map.MapIterableToIterable.compute(MapIterableToIterable.java:58)
	at net.imagej.ops.map.MapIterableToIterable.compute(MapIterableToIterable.java:47)
	at net.imagej.ops.threshold.apply.ApplyConstantThreshold.compute(ApplyConstantThreshold.java:73)
	at net.imagej.ops.threshold.apply.ApplyConstantThreshold.compute(ApplyConstantThreshold.java:50)
	at net.imagej.ops.threshold.AbstractApplyThresholdIterable.compute(AbstractApplyThresholdIterable.java:52)
	at net.imagej.ops.threshold.AbstractApplyThresholdIterable.compute(AbstractApplyThresholdIterable.java:43)
	at net.imagej.ops.special.hybrid.UnaryHybridCF.calculate(UnaryHybridCF.java:61)
	at net.imagej.ops.special.hybrid.UnaryHybridCF.run(UnaryHybridCF.java:71)
	at net.imagej.ops.special.hybrid.UnaryHybridCF.run(UnaryHybridCF.java:97)
	at org.scijava.command.CommandModule.run(CommandModule.java:196)
	at net.imagej.ops.OpEnvironment.run(OpEnvironment.java:960)
	at net.imagej.ops.OpEnvironment.run(OpEnvironment.java:136)
	at net.imagej.ops.OpListingModule.run(OpListingModule.java:68)

Looks like the threshold value is being passed as an IntType, but our image is of UnsignedByteTypes :frown:

[gselzer]

The more I think about this, this is an ImageJ Ops problem. If ImageJ Ops is broadcasting a SearchResult, then it's Ops' job to make sure that we can run that thing, given that the parameters are within the type specifications. I'm tempted to move this issue to ImageJ Ops, what do you think @hinerm?

On the other hand, I don't know how we can fix this; there's no way for us to know that the Op relies on a generic type, since we can't get at that generic type. Do we close this as not planned knowing that it doesn't work?

[gselzer]

I'm closing this, as it is essentially a duplicate of imagej/imagej-ops#648, and this script produces the same issue:

#@ Img input
#@ OpService ops

import net.imglib2.type.numeric.real.DoubleType

out = ops.create().img(input)
ops.threshold().apply(out, input, new DoubleType(10.0))

Error:

java.lang.RuntimeException: java.util.concurrent.ExecutionException: java.lang.ClassCastException: net.imglib2.type.numeric.integer.UnsignedByteType cannot be cast to net.imglib2.type.logic.BitType
	at net.imagej.ops.thread.chunker.DefaultChunker.run(DefaultChunker.java:102)
	at org.scijava.command.CommandModule.run(CommandModule.java:196)
	at net.imagej.ops.OpEnvironment.run(OpEnvironment.java:960)
	at net.imagej.ops.OpEnvironment.run(OpEnvironment.java:157)
	at net.imagej.ops.map.MapUnaryComputers$IIToIIParallel.compute(MapUnaryComputers.java:101)
	at net.imagej.ops.map.MapUnaryComputers$IIToIIParallel.compute(MapUnaryComputers.java:87)
	at net.imagej.ops.threshold.apply.ApplyConstantThreshold.compute(ApplyConstantThreshold.java:73)
	at net.imagej.ops.threshold.apply.ApplyConstantThreshold.compute(ApplyConstantThreshold.java:50)
	at net.imagej.ops.special.computer.BinaryComputerOp.run(BinaryComputerOp.java:85)
	at net.imagej.ops.special.computer.BinaryComputerOp.run(BinaryComputerOp.java:100)
	at org.scijava.command.CommandModule.run(CommandModule.java:196)
	at net.imagej.ops.OpEnvironment.run(OpEnvironment.java:960)
	at net.imagej.ops.OpEnvironment.run(OpEnvironment.java:157)
	at net.imagej.ops.threshold.ThresholdNamespace.apply(ThresholdNamespace.java:95)
	at net.imagej.ops.threshold.ThresholdNamespace$apply.call(Unknown Source)
	at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:47)
	at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:125)
	at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:157)
	at New_.run(New_.groovy:7)
	at org.codehaus.groovy.jsr223.GroovyScriptEngineImpl.eval(GroovyScriptEngineImpl.java:317)
	at org.codehaus.groovy.jsr223.GroovyScriptEngineImpl.eval(GroovyScriptEngineImpl.java:155)
	at org.scijava.plugins.scripting.groovy.GroovyScriptLanguage$1.eval(GroovyScriptLanguage.java:97)
	at javax.script.AbstractScriptEngine.eval(AbstractScriptEngine.java:264)
	at org.scijava.script.ScriptModule.run(ScriptModule.java:164)
	at org.scijava.module.ModuleRunner.run(ModuleRunner.java:163)
	at org.scijava.module.ModuleRunner.call(ModuleRunner.java:124)
	at org.scijava.module.ModuleRunner.call(ModuleRunner.java:63)
	at org.scijava.thread.DefaultThreadService.lambda$wrap$2(DefaultThreadService.java:225)
	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
	at java.lang.Thread.run(Thread.java:750)
Caused by: java.util.concurrent.ExecutionException: java.lang.ClassCastException: net.imglib2.type.numeric.integer.UnsignedByteType cannot be cast to net.imglib2.type.logic.BitType
	at java.util.concurrent.FutureTask.report(FutureTask.java:122)
	at java.util.concurrent.FutureTask.get(FutureTask.java:192)
	at net.imagej.ops.thread.chunker.DefaultChunker.run(DefaultChunker.java:96)
	... 31 more
Caused by: java.lang.ClassCastException: net.imglib2.type.numeric.integer.UnsignedByteType cannot be cast to net.imglib2.type.logic.BitType
	at net.imagej.ops.threshold.apply.ApplyThresholdComparable.compute(ApplyThresholdComparable.java:46)
	at net.imagej.ops.special.computer.BinaryComputerOp.compute(BinaryComputerOp.java:93)
	at net.imagej.ops.map.Maps.map(Maps.java:297)
	at net.imagej.ops.map.MapUnaryComputers$IIToIIParallel$1.execute(MapUnaryComputers.java:106)
	at net.imagej.ops.thread.chunker.DefaultChunker$1.run(DefaultChunker.java:76)
	at org.scijava.thread.DefaultThreadService.lambda$wrap$1(DefaultThreadService.java:211)
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
	... 4 more