Comments (8)
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.
Related Issues (20)
- Building a kdTree is slow for repeated values HOT 1
- More specific type hierarchy for volatile types
- Remove unnecessary overrides of IterableRealInterval.iterator()
- Spliterators for standard NativeImgs
- Create LocalizableSamplerStream HOT 4
- Explore consequences of adding ImgLibStream wrapper HOT 1
- Stream API documentation
- Improve Point.setPosition
- Consistent toString() implementations
- Deprecate AbstractLocalizingCursor
- Simplify AbstractArrayCursor hierarchy
- Reduce allocation size for Cell objects in CellImg
- Add Util.printCoordinates(Localizable)
- Implement CellLocalizingSpliterator and PlanarLocalizingSpliterator
- Simplify static creation methods
- Views.bundle returns BundleView, but BundleView class is not public HOT 3
- Modularize core ImgLib2 projects HOT 1
- Improve Intervals methods
- WriteConvertedCursor constructor fails with ArrayIndexOutOfBoundsException HOT 6
- Add documentation for SamplerConverter
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from imglib2.