Consider making Projectors into SciJava Common plugins about imglib2 HOT 8 OPEN

We could use the Contingent interface with the conforms method from image-ops.

from imglib2.

@dietzc Definitely that pattern, yes. Not sure if we would be able to reuse the actual interface though. Firstly, we'd need to move Contingent deeper into the stack, to imglib2 core. Secondly, we'd have to set the Projector's fields before calling conforms, just like we do with ops. The more "natural" approach would be to have a supports(A a, B b) sort of method so you can just ask, flat out: "do you like these arguments?"

from imglib2.

I thought that the ImgLib2 maintainer did not want to add the scijava-common dependency, and that we set out to show the worth of scijava-common by implementing imagej-ops? I totally hate the idea of pushing a dependency down the throat of the ImgLib2 trio when they do not see the value of it.

from imglib2.

@dscho No one is "pushing a dependency down the throat" of anyone. I filed this issue in response to discussion on PR #23, specifically @tpietzsch's request:

@ctrueden @dietzc Wrt. to scijava-commons, it would be educational to see how well this would work in this case. If one of you finds time to give it a try, I would be very interested.

I wrote the issue subject as "Consider making..." to make it clear that this issue is not about implementing an SJC-based solution and then merging to master without @tpietzsch's approval. I am also personally in no hurry to tackle this issue, but since @dietzc expressed enthusiasm, I filed the issue so we wouldn't forget about this idea.

from imglib2.

@ctrueden ah, okay. I misunderstood. I just wanted to make sure that we do not distract scarce resources from getting imagej-ops into shape... After that, @tpietzsch should be able to see the benefit and add the dependency himself, making use of the great facilities provided in scijava-common.

from imglib2.

@dscho: nod Personally I am not really certain whether ImgLib2 should depend on SciJava Common. I guess it depends on what sorts of things we want in ImgLib2 core, versus other components such as imglib2-meta (which already use SJC). There is something to be said for the fact that imglib2 currently lives at the bottom of the SciJava stack and has no other deps. But if there are compelling use cases like automatic Projector selection, then adding the dependency does not really change that much. And it would definitely be preferable to reinventing subsystems, copy/pasting code, etc.

from imglib2.

@ctrueden we will need things like multi-threading awareness (for nested algorithms, as I explained in person) and progress reporting. If ImgLib2 wants to do that, it should re-use the work of scijava-common rather than implementing an incompatible version thereof, making everybody involved miserable. If ImgLib2 does not want to do that, it is not the place for (re-)usable algorithms, but -- as I expect -- imagej-ops.

from imglib2.

@dscho: For multithreading, @dietzc has pending PR #67 which allows specification of an ExecutorService which seems sufficient for the time being. We can reevaluate that later if it is not flexible enough. I agree about progress reporting, but like you, I want to focus on providing that feature in OPS and then express all the ImgLib2 algorithms as OPS. Core ImgLib2 should stay focused on the lower level framework, not about any specific algorithms or even an algorithms framework, since that is what OPS provides.

IMO it is too early to tell whether, e.g., imglib2-algorithms et. al will be completely obsoleted by OPS, or merely complemented by it...

from imglib2.