Before we plunge ahead with this, I'd like to better understand why we need to move away from allowing thresholding on Iterable.

The main problem here is that, for Computer to Function adaptation to work here, we need a Function<T, U> engine.create Op to produce the output, where T is a supertype of Iterable<T> and U is a subtype of Iterable<BitType>. The former is problematic here, as no supertype of Iterable<T> would contain enough information to make an Img<BitType>, for example.

What I realized we could do, though, is something like I did here. The additions of type variables U and V are ugly, however they do let us circumvent the Iterable<T> problem by asking for a Function<U, V>, where U is now Img<ShortType>. The only unfortunate things now are that:

1. The error message is ugly (note that if you just call ops.help("threshold.mean"), you'll get the simple descriptions which remove the type variables):

org.scijava.ops.api.OpMatchingException: No Ops found matching this request.

Name: "threshold.mean", Types: java.util.function.Function<net.imglib2.img.array.ArrayImg<net.imglib2.type.numeric.integer.UnsignedShortType, net.imglib2.img.basictypeaccess.array.ShortArray>, net.imglib2.RandomAccessibleInterval<net.imglib2.type.logic.BitType>>
Input Types: 
		* net.imglib2.img.array.ArrayImg<net.imglib2.type.numeric.integer.UnsignedShortType, net.imglib2.img.basictypeaccess.array.ShortArray>
Output Type: 
		* net.imglib2.RandomAccessibleInterval<net.imglib2.type.logic.BitType>

Perhaps you meant one of these:
threshold.mean:
	- org.scijava.ops.image.threshold.ApplyThresholdMethod$Mean
		> input : U
		> output : @CONTAINER V
	- org.scijava.ops.image.threshold.mean.ComputeMeanThreshold
		 Implements a mean threshold method by Glasbey.
		> input : net.imglib2.histogram.Histogram1d<T extends net.imglib2.type.numeric.RealType<T>>
		> output : @CONTAINER T

2. Still doesn't work if you request a RandomAccessibleInterval output, however that would be fixed with ImgLib2 v7.

This pull request has been mentioned on Image.sc Forum. There might be relevant details there:

https://forum.image.sc/t/fiji-friends-weekly-dev-update-thread/103718/52

I've given this PR some TLC - I'm much happier with how things work:

• Thresholding on RAI, instead of on Iterable - I'm not terribly sure about this change, as it limits the scope of what we can threshold, however it enables better efficiency and I don't think we ever really needed the Iterables capability...what do you think @hinerm?

This is no longer the case - I used type variables for more powerful dependency resolution, as I alluded to here:

What I realized we could do, though, is something like I did here. The additions of type variables U and V are ugly, however they do let us circumvent the Iterable<T> problem by asking for a Function<U, V>, where U is now Img<ShortType>. The only unfortunate things now are that:

The ops.helpVerbose calls are still a bit confusing, but this should be solved in another PR:

	- org.scijava.ops.image.threshold.ApplyThresholdMethod$Mean
		> input : I
		> output : @CONTAINER J

This pull request has been mentioned on Image.sc Forum. There might be relevant details there:

https://forum.image.sc/t/fiji-friends-weekly-dev-update-thread/103718/60