Merge with ImageJ Ops? Or make an official ImageJ subproject?

[ctrueden]

One goal of ImageJ Ops is to provide a central, curated collection of image processing algorithms, which are easy to use from scripts. It would be very helpful to hear about where/how Ops falls short, and take steps to improve the situation. We do have plans to make Ops easier to use, and easier to extend.

Could we start a thread on the ImageJ Forum where we discuss these things, and figure out how to move the project forward for the whole community's benefit, rather than splintering it into side projects like this?

See also benoalo/CIP#4.

[holgerbrandl]

@benoitlo and I and others were discussing DSLs for imgproc recently, and I suggested that kotlin maybe an interesting option because of all the cool language features it provides. So kip is meant just as a prototype that mimics cip but using kotlin.

I don't know enough about imgproc to judge if ops falls short in any regard. From a java perspective, I actually like the way it is done. At least I could use it with almost no warmup.

It's more the java language limitations of Java that imho limit its scope for imgproc prototyping. E.g. it lacks named and default parameters, extension functions (which is all kip is doing on top of ops/imglib2), type inference, scripting support, excellent tooling when building prototypes, etc.

And imho taking some artifacts and building something fun on top is the core of OSS and not splintering into side projects.

[ctrueden]

Thanks for your comments, @holgerbrandl. I would love to discuss more in person at the upcoming DAIS hackathon if you are available!

About "splintering into side projects": I agree with you that building fun projects on top of other projects is the OSS way. But there is also definitely a "splintering" effect if multiple folks build blocks on top of blocks in similar directions, but without communicating or pushing common elements and ideas upstream. I'll reiterate what I wrote in benoalo/CIP#4: A question to ask yourself is "do you want this project to have community impact"? If the answer is an honest "yes" then keeping it separate makes it much less accessible to the ImageJ community as a whole, for a variety of reasons. Whereas improving the core ImageJ scripting patterns, and updating the tutorials to use them, makes the ideas extremely accessible. All of that said, I completely understand and sympathize with experimental code needing to stay separate for rapid development, and to avoid code paralysis due to early adoption. I just filed this issue to communicate that I am enthusiastic to keep an open dialogue about useful things being made available to the broadest possible audience once they are mature enough.