Hi Jay, > is there the potential to create a OpService#run method that would > take, for example, alternating strings and objects to allow calls to > be "more explicit" or "transparent"
All Ops are Modules, and the ModuleService has this feature: http://jenkins.imagej.net/job/SciJava-common-javadoc/javadoc/org/scijava/command/CommandService.html#run(java.lang.Class,%20boolean,%20java.lang.Object.. .) Or more type-safe using a Map<String, Object>: http://jenkins.imagej.net/job/SciJava-common-javadoc/javadoc/org/scijava/command/CommandService.html#run(java.lang.Class,%20boolean,%20java.util.Map) Regards, Curtis On Fri, Oct 3, 2014 at 5:25 PM, Jay Warrick <[email protected]> wrote: > Very helpful. Thanks. > > Not that I need this capability, but is there the potential to create a > OpService#run method that would take, for example, alternating strings and > objects to allow calls to be "more explicit" or "transparent" (i.e., > OpService#runExplicit("myOp", "max", max, "min", min) and potentially more > extensible in case order of arguments change or there end up being > additional optional arguments. Obviously you link yourself to names as > opposed to order. I guess there is always a give and take with these things. > > I could try and draft up such a method if you think it useful and doesn't > go against what you are trying to shoot for. > > Cheers, > > Jay > > > > On Oct 3, 2014, at 12:39 PM, Curtis Rueden <[email protected]> wrote: > > Hi Jay, > > > 1) When should we use the "Command" style method of doing things where > > all information is specified using the @Parameter methodology and run > > via the "run" method, and when should we use the "Function" style of > > things with a typed input and output "compute" method? > > Advantages/disadvantages of each? Can you get by with either? > > We started OPS with the "Command" paradigm, then found that for the vast > majority of ops, there was one "special" input over which you want to > iterate (either per pixel, or in a multi-threaded context, or both), and > one main output of the op. That common case is a Function (you extend > either AbstractStrictFunction or AbstractOutputFunction, depending on > whether you want to force the caller to pass in a preallocated output or > not). > > In short: use Function if you want your op to usable by the "map" op to > execute it iteratively over an entire image (e.g., an Iterable or > IterableInterval). Use a plain Op if you don't need that, don't care or are > lazy. > > As always in programming: model your code after existing code ("when in > Rome") for best results. > > > 2) I couldn't see how some of the @Parameter objects would be or are > > injected or set. > > Calling OpService#run to execute the op automatically finds the best > matching op, and then injects the parameter values in the specified order. > > > how are potential ambiguities resolved when trying to set two > > parameters of the same type? > ... > > Order that it is listed in the Op class def and order of args provided > > to the ops.run() methods? > > Yes. The order defined in the class must match the order of arguments > given to the OpService#run method. > > Call OpService#help(String) for a full list of ops with the given name, > including expected parameters. > > Regards, > Curtis > > On Thu, Oct 2, 2014 at 4:53 PM, Jay Warrick <[email protected]> wrote: > >> Curtis - Sweet! I like it. I can see myself making small packages of Ops >> for things we do in our research that we could easily make available for >> others. It's also a great way for us to reuse capabilities across different >> JEX functions we create that allows us to share them with the rest of the >> community instead of just creating static methods hoarded in various >> "utility classes" in our software, not that we would ever do that :-) >> >> Curtis and everyone else :-) - First of all, thanks to all for their hard >> work to lay the foundation for this really useful Ops package. 2 things, >> though, I would appreciate some help with. Although I've looked at most of >> the Ops and the tutorials on creating and using Ops, I still have a couple >> questions. >> >> 1) When should we use the "Command" style method of doing things where >> all information is specified using the @Parameter methodology and run via >> the "run" method, and when should we use the "Function" style of things >> with a typed input and output "compute" method? Advantages/disadvantages of >> each? Can you get by with either? >> >> 2) I couldn't see how some of the @Parameter objects would be or are >> injected or set. What is the "sleekest" method for setting these parameters >> if I wanted to use these Ops in my own program without resorting to setting >> private Parameter fields accessible etc (e.g., the @Parameter >> private T threshold;" of the ApplyConstantThreshold.java Op)? Am I >> forgetting some tool/method for easily injecting/setting Op/Command >> parameters? It seems like calls to ij.op().<whatever> only pass parameters >> to compute method and don't do any @Parameter object injection/setting. Am >> I wrong? Or, eventually, would these Ops have getters and setters. Are >> getters and setters automatically generated already that I'm not aware of >> by just looking over the code? >> >> Thanks, >> >> Jay >> >> >> >> >> On Oct 2, 2014, at 12:35 PM, Curtis Rueden <[email protected]> wrote: >> >> Hi Jay, >> >> > Am I right that Ops sort of occupies the niche between ImgLib2 and >> > ImageJ Plugins... something that makes it easier to do the image >> > manipulations but can be reused a bit more easily given they don't >> > require many of the Service parameters and preprocessors that many of >> > the plugins take/need? >> >> Yes, OPS is intended for pure image processing operations and functions. >> The rule of thumb is that they be deterministic, and have no side effects. >> So you give same inputs, you get same outputs, every time. Many of them are >> also multithreadable, though that is not a requirement. And OPS are also >> supposed to be "static" rather than dynamic -- i.e., they shouldn't have a >> variable number of input or output parameters, unlike commands in general. >> >> That said, OPS are still allowed to depend on services, but it is >> expected that the service methods you call will not compromise the >> determinism of the op -- i.e., only utility methods of services should >> really be used. Perhaps in the future we could add annotations to each >> service method indicating what sort of method it is, and hence where it is >> "safe" to use. >> >> I want to thank you for your feedback and discussion from a few months >> ago, regarding reuse of ImageJ2 commands in JEX. Your perspective provided >> some of the inspiration for the design of OPS, because it became clear that >> we need a "pure functional" layer for image processing that does not rely >> on side effects from services, etc. The idea is that KNIME Image >> Processing, CellProfiler, OMERO, JEX, etc., can all consume and expose the >> ops with the assumption that they will behave well (work headless, etc.). >> >> Regards, >> Curtis >> >> >> On Thu, Oct 2, 2014 at 12:08 PM, Jay Warrick <[email protected]> wrote: >> >>> Looks promising. Am I right that Ops sort of occupies the niche between >>> ImgLib2 and ImageJ Plugins... something that makes it easier to do the >>> image manipulations but can be reused a bit more easily given they don't >>> require many of the Service parameters and preprocessors that many of the >>> plugins take/need? >>> >>> On Oct 1, 2014, at 4:58 PM, Curtis Rueden <[email protected]> wrote: >>> >>> Hi everyone, >>> >>> The ImageJ2 and KNIME Image Processing teams met in Madison during the >>> week of September 15 - 19, to work on ImageJ OPS, which seeks to be a >>> unifying library for scientific image processing. >>> >>> On behalf of the OPS development team, I am pleased to announce the >>> results of that hackathon, including accomplishments, project goals and >>> milestones. See the news post for full details: >>> >>> http://imagej.net/2014-10-01_-_ImageJ_OPS_Hackathon >>> >>> Regards, >>> Curtis Rueden >>> ImageJ2 project lead >>> _______________________________________________ >>> ImageJ-devel mailing list >>> [email protected] >>> http://imagej.net/mailman/listinfo/imagej-devel >>> >>> >>> >> >> > >
_______________________________________________ ImageJ-devel mailing list [email protected] http://imagej.net/mailman/listinfo/imagej-devel
