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 <ctrue...@wisc.edu> 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 <warr...@wisc.edu> 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 <ctrue...@wisc.edu> 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 <warr...@wisc.edu> 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 <ctrue...@wisc.edu> 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
>>> ImageJ-devel@imagej.net
>>> http://imagej.net/mailman/listinfo/imagej-devel
>>
>>
>
>
_______________________________________________
ImageJ-devel mailing list
ImageJ-devel@imagej.net
http://imagej.net/mailman/listinfo/imagej-devel
