<div dir="ltr"><div><div>Hi Stefan and Birgit,</div><div><br></div><div>More than one year later! Better late than never, hopefully.</div><div><br></div><div>> > Maybe we need a way to formally flag these "required before</div><div>> > initialize" parameters in the annotation? What do you think?</div><div>> > Would that help you?</div><div>></div><div>> This would be different from autoFill() ?</div><div><br></div><div>Yes. The autoFill attribute is a way of saying to preprocessors: "If you do some sort of automatic value setting, do not do it to me." E.g., it lets you have a single image or display input without the ActiveImagePreprocessor or Active*DisplayPreprocessor populating it. In the case of the ImageJ UI, the InputHarvester preprocessor will then include it in the dialog box (since the parameter is still not marked resolved), so the user can explicitly select the desired object.</div><div><br></div><div>> Yes and no.</div><div>> </div><div>> In a way it makes responsibilities clear, in so far I feel comfortable</div><div>> with it.</div><div><br></div><div>Agreed, I like the declaration of intent there. But I'm not sure it would help anything programmatically.</div><div><br></div><div>> However, it seems to me that there are (potentially very heavy)</div><div>> restrictions on the parameters which may be filled in advance</div><div>> (automaticcal and not by the user) in a sensible way. As far as I</div><div>> understand ij2 fills in parameters with what I think you called</div><div>> AutoFooPreprocessors, so active image and active display?</div><div><br></div><div>Indeed. Preprocessor plugins are contextual, meaning they have access to the entire state of the context. And since the context is extensible, I really have no idea what sorts of parameters are "sensible" to fill or not. It really depends on the use cases of the application(s) involved.</div><div><br></div><div>> I cannot come up with further ones. How would we fill in an int</div><div>> parameter without knowledge of its meaning/sematics?</div><div><br></div><div>Right. Of course, the meaning/semantics would need to be known somehow. But that is outside the scope of the SciJava library design. As I said above, I can imagine (abstractly) that someone designs an application with various preprocessors that populate various parameters, including int[], in some predefined way for its use cases.</div><div><br></div><div>> And even for images is only possible for commands with exactly one</div><div>> image or display. Obviously we could introduce a further flag for an</div><div>> image parameter to notify, that I what to be assigned the active image</div><div>> with. But this seems pretty specific. And probably not generic to be</div><div>> introduce to scijava but rather deferred to the "application", e.g.</div><div>> imagej.</div><div><br></div><div>I agree; that flag would be too specific. That's what the preprocessor design is for: to avoid overspecifying how parameters might get populated, and instead leave it to the extensions (preprocessors) available to the context. The ImageJ paradigm is to have an "active image" which we can then use for populating image parameters, but this is far from the only valid paradigm.</div><div><br></div><div>> And there might be aplications which call for more the two layers?</div><div><br></div><div>In a way, the preprocessor design accommodates N layers, because the preprocessors are run in priority order. But in practice there are two layers when it comes to the initializers: preprocessors that come before InitPreprocessor, and preprocessors that come after it. I think this is OK and there is no need to subdivide initialization farther than that, but if you have a use case that illustrates otherwise, we can figure it out.</div><div><br></div><div>> Summing up, I am afraid that I do not have a cute idea.</div><div><br></div><div>Well, your cute idea was in the follow-up mail. We'll get to that below...</div><div><br></div><div>> Of course I appreciate the functionality the set initial values or</div><div>> make the type of parameters depending on image features (like</div><div>> dimensionality, range of values). Still adding parameters seems</div><div>> awkward to be. Could we come by with "only" changing types of</div><div>> parameters. E.g. for DuplicateImage not add one parameter for each</div><div>> axes rather have one array parameter with its length determined by the</div><div>> dimensionality? And may be indicate via annotations, depending on</div><div>> which other parameter(s) the type of this parameter will change?</div><div><br></div><div>Yes, this is very related to a recent reply I sent to imagej-devel in another thread [1]. I will recapitulate it here:</div><div><br></div><div>There are five different classes of modules:</div><div><br></div><div>1) Totally fixed, with inputs and outputs known in advance.</div><div>2) Updates parameter attributes (such as choices—but not # or type of inputs/outputs) once during initialization.</div><div>3) Updates parameter number and type (i.e., adding/removing inputs/outputs) once during initialization.</div><div>4) Updates parameter attributes repeatedly e.g. during callbacks.</div><div>5) Updates parameter number and type repeatedly e.g. during callbacks.</div><div><br></div><div>These five types of modules challenge us in different ways:</div><div><br></div><div>#1 is easy -- I think everything can support it easily.</div><div><br></div><div>#2 and #4 do not update the fundamental aspects of the module: the name and types of the parameters are known. So such modules can be classified as fundamentally "well behaved".</div><div><br></div><div>#3 and #5 are more difficult because they are fully dynamic: the names and types of parameters are not known a priori.</div><div><br></div><div>I agree with you that it would be nice if #2 and #4 type commands did not need to extend DynamicCommand, but instead some other abstract class that indicates they are well behaved from a typing perspective.</div><div><br></div><div>I filed an issue for it:</div><div><a href="https://github.com/scijava/scijava-common/issues/179">https://github.com/scijava/scijava-common/issues/179</a></div><div><br></div><div>While at it, I also filed an issue for commands which are iteratively dynamic (i.e., alter their parameters during callbacks):</div><div><a href="https://github.com/scijava/scijava-common/issues/180">https://github.com/scijava/scijava-common/issues/180</a></div><div><br></div><div>Though the distinction of "iteratively dynamic" may go away after implementing your idea to totally eliminate initializers in favor of callbacks.</div><div><br></div><div>And for what it's worth, I agree that better support for List and array parameters will often times avoid the need to use dynamic modules at all. This is something we have wanted for a long time:</div><div><a href="https://github.com/scijava/scijava-common/issues/118">https://github.com/scijava/scijava-common/issues/118</a></div><div><br></div><div>> Thinking of module and parameter intitalizers it seems to be that I</div><div>> get more unsure. Is it exactly to do processing between the two layers</div><div>> of parameters.</div><div><br></div><div>Yes, that is one of the purposes, as discussed above. But not the sole purpose.</div><div><br></div><div>> And it is to add further parameters</div><div><br></div><div>In the case of dynamic modules, yes. And I would classify that as a "processing between two layers" use case.</div><div><br></div><div>> and set initial values to parameters?</div><div><br></div><div>Yes, that was the primary intended use case: when you want to set the initial value of a parameter and it cannot be expressed as a simple assignment. That is: if you want the default sigma to be 2.5, you simply write:</div><div><br></div><div> @Parameter</div><div> private double sigma = 2.5;</div><div><br></div><div>But if you want to define it by writing code -- presumably to somehow derive its initial value from the application state -- you need an initializer. It is not enough to write:</div><div><br></div><div> @Parameter</div><div> private double sigma = initialSigma();</div><div><br></div><div> private double initialSigma() {</div><div> ...</div><div> }</div><div><br></div><div>Because in that case, the initialSigma method is called when the object is first instantiated, but before any context is injected. The initializer, conversely, is typically called at a very specific point in the preprocessing chain.</div><div><br></div><div>> Are initial parameter values execulsively meant to serve as defaults</div><div>> for the user or is it required that some initial values are set (in</div><div>> order to properly run the command)?</div><div><br></div><div>There is no hard assumption that initializers leave parameters "open" for further user alteration. Actually, a dynamic command could set any number of parameters to resolved during initializer routines, and then those parameters would not be shown to the user in the input harvester.</div><div><br></div><div>As discussed earlier in this thread, the precondition of run is that all required parameters be non-null when run() is called. This can be achieved by the preprocessing chain, or because some/all parameter values were passed to the moduleService.run method and prepopulated that way.</div><div><br></div><div>> If so: would this mean that for running a command head less in a non interactive way makes the distiction of two layers is obsolete?</div><div><br></div><div>The typically non-interactive use case is to pass all parameter values explicitly, which would make all the initializer stuff moot, yes. But it is not a hard requirement -- it really depends on your definition of "non-interactive"; if the preprocessing chain fulfills missing parameters in some other way, that is also acceptable from the standpoint of fulfilling the preconditions of run().</div><div><br></div><div>> running the init preprocessor gives</div><div>> -----</div><div>> Exception in thread "main" java.lang.IllegalStateException: Context</div><div>> already injected: org.scijava.AbstractContextual#context</div><div><br></div><div>Given the long time frame since you sent this: did you resolve this issue in an acceptable way? Or is it still a problem for you? If it is still a problem, I will be happy to look in more detail and give some advice -- in a much more timely fashion this time.</div><div><br></div><div>> Is this intended, i.e. that the init preprocessor for a module may be</div><div>> run only once?</div><div><br></div><div>Yes, module.initialize() is intended to be called only once. To execute a module again, create a new instance each time. The current code does still have this requirement, because CommandModule#initialize() injects the context, which is only allowed once.</div><div><br></div><div>> What we want to do is essentially the following:</div><div>> * The user selects a Command via the GUI and we create a Window</div><div>> displaying the input parameters.</div><div>> * The user may change/supply these parameters and run the Command.</div><div>> * Upon return a window displaying the results pops up.</div><div>> * However, the first window displaying the input parameters is still</div><div>> available, the user may change one/some parameters an rerun the</div><div>> command.</div><div>> * This eases testing various parameter values or the same set of</div><div>> parameters on different images without the need to repeatatly select</div><div>> an operator/command.</div><div>></div><div>> Have you further advise how we can accomplish this, i.e. reusing a</div><div>> command module?</div><div><br></div><div>I think you can accomplish all of the above without reusing the same module instance, but instead creating a new one every time. Is that how you are currently doing it these days?</div><div><br></div><div>Alternately, if you don't call initialize() beyond the first time, that would probably do the trick as well, although reusing module instances is not a use case we have considered much.</div><div><br></div><div>> BTW: I prefer to not set the parameters via the moduleService.run</div><div>> method, as the parameters are set elsewhere (either by the user via a</div><div>> GUI configuring the operator/command e.g. from grappa, or by parsing</div><div>> command line argument in case of the command line oprunner.</div><div>> Additionaly I rather invoke the moduls run-method directly, as it</div><div>> seems to me that via moduleservie a new thread is started, and at this</div><div>> point we like to have this under control.</div><div><br></div><div>All makes sense. You can populate the parameters prior to run() in whatever way you see fit. If you want to do it after initialization, you could create your own preprocessor that does it. Or just set them directly right away. Whatever works.</div><div><br></div><div>> it seems, that the init preprocessor assigns the service parameters of</div><div>> a Command, not the Service preprocessor as I expected. Is the correct?</div><div>> (Probably related to "shadowing" the Service and Context parameters of</div><div>> a Command)</div><div><br></div><div>Yes, because the InitPreprocessor calls initialize() and for CommandModules that injects the context. And InitPreprocessor happens before ServicePreprocessor. I discussed this wrinkle in my previous reply. </div><div><br></div><div>> BTW: what is the sematics of injecting a context (into a module?)</div><div><br></div><div>Does this answer your question:</div><div><a href="https://github.com/scijava/scijava-common/blob/scijava-common-2.44.2/src/main/java/org/scijava/Context.java#L340-L360">https://github.com/scijava/scijava-common/blob/scijava-common-2.44.2/src/main/java/org/scijava/Context.java#L340-L360</a></div><div>?</div><div><br></div><div>Note that "injecting a Context" is something done to Java objects, not modules per se. Initializing a CommandModule instance injects its context into its associated Command instance [2]. But for other sorts of modules such as ScriptModule, there is no associated Java object.</div><div><br></div><div>> > Do you think that Commands should also include service and context</div><div>> > inputs when iterating them? If so, we can try removing that</div><div>> > exclusion and see what explodes... ;-)</div><div>></div><div>> We would not need them rather hide the from the user.</div><div><br></div><div>OK, then I will not worry about changing this behavior any time soon -- I think it is tolerable for the time being. But unfortunately, to fully support all modules (not just commands), you still need the logic to hide service and context inputs, since other modules types like scripts will often have them.</div><div><br></div><div>> no, we are hapy with one, just have to get hold of it (and use it in a</div><div>> static way)</div><div><br></div><div>Since you only need a single Context, you presumably either: A) have a standalone application, in which case you should just spin up a Context and keep a reference to it; or: B) have an ImageJ plugin, in which case you should implement Command and write "@Parameter private Context context" in your command and you'll magically get the context injected. Actually, it is most direct in that case to declare @Parameters for all your needed services, rather than the context itself, since typically what you will want to do is make various service calls.</div><div><br></div><div>> We think we could do without command and parameter initializers but</div><div>> work only with the parameter's callback function</div><div><br></div><div>Great idea. This would elegant, and often superior in case of later changes to the relevant parameter(s). We can try to simplify this for SJC3, which is slated for release within the next few months [3]. I filed an issue for it [4]. There are some minor obstacles in certain cases, which I describe on the issue if you are interested, but they all seem surmountable.</div><div><br></div><div>> What if this callback reqires/assumes one or several other parameters</div><div>> to aready have be set? It seems to be, that this necessarily is the</div><div>> responsibility of the callback function (resp. its programmer) to</div><div>> handle this.</div><div><br></div><div>Agreed. This is a secondary parameter which depends on multiple primary parameters. So they all need callbacks which recompute the secondary parameter -- presumably by calling the same helper method, which does nothing if any of the needed primary parameters are still null.</div><div><br></div><div>> Otherwise the Command or its Parameters have to declare a predefine</div><div>> order in which parameters have to be set. (Which we have considered to</div><div>> introduce to alida/mitobo few years ago but abandoned this idea as it</div><div>> seems to messy/error prone.)</div><div><br></div><div>Again agreed: best not to mandate anything with respect to order.</div><div><br></div><div>> in case of command execution via GUI (in contrast to</div><div>> programmatically): what if not all parameters which add further</div><div>> parameters are filled before the GUI is created and presented to the</div><div>> user and are set by the user? What we are considering is that the GUI</div><div>> to figure out such events have happened and then to adapt the GUI</div><div>> accordingly.</div><div><br></div><div>Yes, ideally we should support that in the ImageJ UI. I believe that CellProfiler handles it by rebuilding the UI every time anything changes structurally. We could do the same thing, and it would be efficient enough -- the ImageJ API requires specific method calls to mutate parameter attributes, which would tell us when a UI rebuild of the input harvester is necessary.</div><div><br></div><div>> How to figure out that set set of parameter (or the type of an already</div><div>> existing parameter) was change by a callback function?</div><div><br></div><div>When a parameter _value_ is changed in a callback, it is typically a direct assignment to a field. So that would not trigger any additional callbacks. This makes infinite loops impossible, but also means it becomes the programmers responsibility to keep track of "transitive parameter dependencies" and update all downstream parameters accordingly.</div><div><br></div><div>When a parameter attribute is changed in a callback (which only DynamicCommands can do), we can easily make the framework publish some event -- individual programmers would not need to deal with this, and everything would "just work."</div><div><br></div><div>> I favour the following guideline: A parameter, e.g. inputDisplay, may</div><div>> add (or remove) parameters to the command exclusively depending of its</div><div>> own value. Furthermore the parameter (names) potentially added by this</div><div>> parameter are disjoint from those parameters added by other parameters</div><div>> of the command. However, it is probably not possible to check or</div><div>> enforce this restriction.</div><div><br></div><div>While that would certainly provide some guarantees, I agree that it is not possible to enforce it. So I would favor not stating any restrictions of that sort.</div><div><br></div><div>> A different issue I came across have a second look at the Parameter</div><div>> annotation, sepcifically its choices: The few examples of usage I had</div><div>> a look at are parameters of type String which announce valid values.</div><div>> It might me worth considering to drop this feature and use Enums</div><div>> instead of Strings which easily allows to generate an approprate</div><div>> selection by the GUI.</div><div><br></div><div>The problem with enums is they are not extensible. So if you want to dynamically generate the choices via callbacks, an enum will not work. IIRC, the module framework does already support enums as dropdown list boxes. But I think there is still a place for the choices attribute, too. Let me know if you see a way around it.</div><div><br></div><div>Regards,</div><div>Curtis</div><div><br></div><div>[1] <a href="http://imagej.net/pipermail/imagej-devel/2015-August/002661.html">http://imagej.net/pipermail/imagej-devel/2015-August/002661.html</a></div><div>[2] <a href="https://github.com/scijava/scijava-common/blob/scijava-common-2.42.2/src/main/java/org/scijava/command/CommandModule.java#L146">https://github.com/scijava/scijava-common/blob/scijava-common-2.42.2/src/main/java/org/scijava/command/CommandModule.java#L146</a></div><div>[3] <a href="https://github.com/scijava/scijava-common/milestones/3.0.0">https://github.com/scijava/scijava-common/milestones/3.0.0</a></div><div>[4] <a href="https://github.com/scijava/scijava-common/issues/181">https://github.com/scijava/scijava-common/issues/181</a></div></div><div><br></div><div><div><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Apr 16, 2014 at 9:47 AM, Stefan Posch <span dir="ltr"><<a href="mailto:posch@informatik.uni-halle.de" target="_blank">posch@informatik.uni-halle.de</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Hi Curtis,<br>
<br>
regarding the concept of initializers I had a discussion with Birgit yesterday<br>
and we came up with the following ideas.<br>
<br>
We think we could do without command and parameter initializers but work only with<br>
the parameter's callback function which - as currently - are to be invoked<br>
upon setting/changing the corresponding parameters value.<br>
<br>
As currently, depending on parameter values, e.g. the image assigned to a Dataset,<br>
the command may add (or remove) parameters. This would be accomplished<br>
by the callback functions of the parameter whose value is the cause for these new parameters.<br>
E.g. the callback function of the inputDisplay of DuplicateImage would add the parameters<br>
(which is currently done by the command initializer).<br>
If some parameters should get (initial) values depending on the value of other<br>
parameters (e.g. your example of setting default brightness/contrast min,max values<br>
to current min,max of the input image) would we again the responsibility of<br>
the callback function of the cause, i.e. the input image.<br>
<br>
This would eleviate us of the need to fill in parameters required for the command initializer.<br>
If a parameter's value is set (either by a pre processor or programmatically)<br>
its callback function takes care of taking the apropriate actions.<br>
<br>
If the pre processor is run, it just needs to set the parameter values it decides to,<br>
and the callback functions would be could automatically.<br>
<br>
What remains is of course:<br>
(i) assume a parameter's value is changed, and its callback method<br>
called accordingly. What if this callback reqires/assumes one or several other parameters<br>
to aready have be set? It seems to be, that this necessarily is the responsibility<br>
of the callback function (resp. its programmer) to handle this. I.e. to check<br>
the validity of other parameters it requires. Otherwise the Command or its Parameters<br>
have to declare a predefine order in which parameters have to be set.<br>
(Which we have considered to introduce to alida/mitobo few years ago but abandoned this<br>
idea as it seems to messy/error prone.)<br>
(ii) in case of command execution via GUI (in contrast to programmatically):<br>
what if not all parameters which add further parameters are<br>
filled before the GUI is created and presented to the user and are set by the user?<br>
What we are considering is that the GUI to figure out such events have happened<br>
and then to adapt the GUI accordingly.<br>
<br>
How to figure out that set set of parameter (or the type of an already existing parameter)<br>
was change by a callback function?<br>
We see two possibilities:<br>
(a) a parameter may announce via its annotation that it (occasionally)<br>
_may_ change paramter definitions and the GUI always assumes that this had happend,<br>
is such a parameter's value has changed (which the GUI knows at it controls this processes).<br>
(b) the callback function is to fire events in case it changes parameter definitions.<br>
<br>
(a) might be similar or be used in analogy to your idea of a parameter to announce "required before initialize",<br>
as the pre processor framework would know that setting of such a parameter probably/potentially<br>
may add parameters and should better be set before creating the GUI to ask the user for<br>
further parameters (and if it accomplishes to set all of those parameters and either excludes them from<br>
the GUI - as currently done by IJ2 for input images - or prohibits changing these parameters,<br>
we get rid of problem (i) stated above).<br>
<br>
<br>
To make things conceptionally easier (for me) I favour the following guideline:<br>
A parameter, e.g. inputDisplay, may add (or remove) parameters to the command<br>
exclusively depending of its own value. Furthermore the parameter (names) potentially<br>
added by this parameter are disjoint from those parameters added by other parameters of<br>
the command. However, it is probably not possible to check or enforce this restriction.<br>
As stated above in (ii) in my view it would be the task of the programmer of the Comand anyway<br>
to cope with more complicated situations and does not affect to supporting "runtime system",<br>
e.g. the functionality to run pre processors and creating GUIs to harvest input vlaues from the user.<br>
<br>
<br>
Best regards<br>
<br>
Stefan<br>
<br>
PS.:<br>
A different issue I came across have a second look at the Parameter annotation, sepcifically<br>
its choices: The few examples of usage I had a look at are parameters of type String which<br>
announce valid values. It might me worth considering to drop this feature and use Enums instead<br>
of Strings which easily allows to generate an approprate selection by the GUI.<br>
<div><div>--<br>
Prof. Dr.-Ing. Stefan Posch,<br>
Institut fuer Informatik, Martin-Luther-Universitaet Halle-Wittenberg<br>
Von-Seckendorff-Platz 1, 06099 Halle (Saale)<br>
phone: <a href="tel:%2B%2B49%20345%2055-24728" value="+493455524728" target="_blank">++49 345 55-24728</a><br>
fax: <a href="tel:%2B%2B49%20345%2055-27039" value="+493455527039" target="_blank">++49 345 55-27039</a><br>
e-mail: <a href="mailto:Stefan.Posch@informatik.uni-halle.de" target="_blank">Stefan.Posch@informatik.uni-halle.de</a><br>
www: <a href="http://www.informatik.uni-halle.de/~posch/" target="_blank">www.informatik.uni-halle.de/~posch/</a><br>
</div></div></blockquote></div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Apr 14, 2014 at 10:16 AM, Stefan Posch <span dir="ltr"><<a href="mailto:posch@informatik.uni-halle.de" target="_blank">posch@informatik.uni-halle.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Hi Curtis,<br><br>thanks for your reply, we are getting ahead, but still questions for running commands<br><span><br>> * The run() method of a module can assume that all required input<br>> parameters have been filled (i.e., are non-null). And the corresponding<br>> post-condition of run() is that all required output parameters are now<br>> filled.<br></span>perfect, the same with us<br><span><br>> * The initialize() method of a module cannot necessarily assume<br>> anything about the state of its parameters. As you pointed out, ImageJ2<br>> has various commands right now that *do* assume certain parameters have<br>> been filled via preprocessing. This works in practice (at least from<br>> the ImageJ application), but is not particularly rigorous.<br>> * Similarly, ImageJ2 has several commands which assume their<br>> initializer has been called, but it is not stated as a formal<br>> precondition. Most probably it makes sense to state that in the<br>> javadoc, would you agree? In other words: if you aren't going to<br>> include the InitPreprocessor in the preprocessing chain, you are still<br>> somehow responsible for calling module.initialize() before calling<br>> module.run(). Is that fair?<br></span>again: perfect<br><span><br>> So the main sticky point is what to do about initialize() requiring<br>> certain parameters to be already filled. This is useful for dynamic<br>> modules, but also just for computing defaults -- e.g., setting default<br>> brightness/contrast min & max values to the current display min max of<br>> the input image. So it seems there are two "layers" of input<br>> parameters: those needed before initialize() and those not needed for<br>> it.<br>> Maybe we need a way to formally flag these "required before initialize"<br>> parameters in the annotation? What do you think? Would that help you?<br></span>This would be different from autoFill() ?<br><br>Yes and no.<br><br>In a way it makes responsibilities clear, in so far I feel comfortable with it.<br><br>However, it seems to me that there are (potentially very heavy) restrictions<br>on the parameters which may be filled in advance (automaticcal and not by the user)<br>in a sensible way. As far as I understand ij2 fills in parameters with what I think<br>you called AutoFooPreprocessors, so active image and active display?<br>I cannot come up with further ones. How would we fill in an int parameter<br>without knowledge of its meaning/sematics?<br>And even for images is only possible for commands with exactly one image or display.<br>Obviously we could introduce a further flag for an image parameter to notify,<br>that I what to be assigned the active image with. But this seems pretty specific.<br>And probably not generic to be introduce to scijava but rather deferred to the<br>"application", e.g. imagej.<br>And there might be aplications which call for more the two layers?<br><br>Summing up, I am afraid that I do not have a cute idea.<br>Of course I appreciate the functionality the set initial values or make the type<br>of parameters depending on image features (like dimensionality, range of values).<br>Still adding parameters seems awkward to be. Could we come by with "only" changing<br>types of parameters. E.g. for DuplicateImage not add one parameter for each axes rather<br>have one array parameter with its length determined by the dimensionality?<br>And may be indicate via annotations, depending on which other parameter(s) the<br>type of this parameter will change?<br><br>Rather more question:<br>Thinking of module and parameter intitalizers it seems to be that I get more unsure.<br>Is it exactly to do processing between the two layers of parameters.<br>And it is to add further parameters and set initial values to parameters?<br>Are initial parameter values execulsively meant to serve as defaults for the<br>user or is it required that some initial values are set (in order to properly<br>run the command)?<br><br>If so: would this mean that for running a command head less in a non interactive way<br>makes the distiction of two layers is obsolete?<br><span><br>> One thing that may interest you is the recent ImageJ OPS announcement:<br></span>> [1]<a href="http://developer.imagej.net/2014/04/04/announcing-imagej-ops" rel="noreferrer" target="_blank">http://developer.imagej.net/2014/04/04/announcing-imagej-ops</a><br><span>> An Op is just an ImageJ command intended to be fully functional --<br></span>That sounds great ...<br><br>> Hi Stefan,<br>> Thanks. Rather than doing this:<br>> CommandInfo testopInfo = new CommandInfo(IJTestOp.class.getName());<br>> testopModule = (CommandModule) testopInfo.createModule();<br>> I suggest instead:<br>> CommandInfo testopInfo = commandService.getCommand(IJTestOp.class);<br>> testopModule = (CommandModule)<br>> moduleService.createModule(testopInfo);<br><br>the advise you gave works fine, however only for running a module for a given Command once.<br> (see attached source of RunTestOp.java, the zip is a tiny maven project ready to import to eclipse.<br> hopefully I do not forget the attachment again :-)<br><br> in short we have<br> CommandInfo testopInfo = commandService.getCommand(IJTestOp.class.getName());<br> CommandModule testopModule = (CommandModule)moduleService.createModule( testopInfo);<br><br> set some parameters<br><br> run the service and init preprocessor on the module, then<br><br> testopModule.run();<br> or as an alternative<br> moduleService.run(testopModule, false);<br><br> running the init preprocessor gives<br>-----<br>Exception in thread "main" java.lang.IllegalStateException: Context already injected: org.scijava.AbstractContextual#context<br> at org.scijava.Context.inject(Context.java:293)<br><span> at imagej.command.CommandModule.initialize(CommandModule.java:144)<br> at imagej.module.process.InitPreprocessor.process(InitPreprocessor.java:61)<br></span> at mainroutine.RunTestOp.main(RunTestOp.java:62)<br>------<br><br> Creating a new module for the same CommandInfo fixes the problem (line 60)<br><br> Is this intended, i.e. that the init preprocessor for a module may be run only once?<br> This would pose a serious problem to us:<br><br> What we want to do is essentially the following:<br> The user selects a Command via the GUI and we create a Window displaying the input parameters.<br> The user may change/supply these parameters and run the Command.<br> Upon return a window displaying the results pops up.<br> However, the first window displaying the input parameters is still available, the user may<br> change one/some parameters an rerun the command.<br> This eases testing various parameter values or the same set of parameters on different<br> images without the need to repeatatly select an operator/command.<br><br> Have you further advise how we can accomplish this, i.e. reusing a command module?<br><br> BTW: I prefer to not set the parameters via the moduleService.run method, as the parameters<br> are set elsewhere (either by the user via a GUI configuring the operator/command e.g. from grappa,<br> or by parsing command line argument in case of the command line oprunner.<br> Additionaly I rather invoke the moduls run-method directly, as it seems to me that<br> via moduleservie a new thread is started, and at this point we like to have this under control.<br><br> it seems, that the init preprocessor assigns the service parameters of a Command,<br> not the Service preprocessor as I expected. Is the correct?<br> (Probably related to "shadowing" the Service and Context parameters of a Command)<br><br> BTW: what is the sematics of injecting a context (into a module?)<br><span><br>> So this is certainly inconsistent and confusing. Do you think that<br>> Commands should also include service and context inputs when iterating<br>> them? If so, we can try removing that exclusion and see what<br>> explodes... ;-)<br></span>We would not need them rather hide the from the user.<br><span><br>> If you urgently need support for multiple simultaneous ImageJ contexts<br>> created with the default constructor while ij-legacy is on the<br>> classpath, and you want to try fixing the bug yourself, we would be<br>> happy to elaborate further so that you can give it a shot.<br></span>no, we are hapy with one, just have to get hold of it (and use it in a static way)<br><br>Again, thanks again<br><br>best regards Stefan<br></blockquote><div><br></div></div></div></div>