[ImageJ-devel] @parameter choice update in component callback

[Curtis Rueden]

Hi Adrian,

> Thanks for the suggestion, which almost does the job, except that the
> initialization also depends on a parameter
>
> @Parameter(persist = false) private RectangleOverlay roi;
>
> which appears to be populated only after the initializer is called
> (its value is null in the initializer and valid in the run() method).

Hmm, that should not be the case. Commands that include a single overlay
parameter should automatically draw from the active image's active overlay,
when possible [1]. This happens _before_ the initializers are called [2]
(because Priority.VERY_HIGH_PRIORITY > Priority.HIGH_PRIORITY).

The issue might be typing-related: try using Overlay instead of
RectangleOverlay and see if that makes a difference. If so, it is probably
a limitation of the ActiveOverlayPreprocessor [1]; patches welcome.

Alternately: can you post an MVCE [3, 4] illustrating the issue?

> do I have to write a Preprocessor of some sorts

This is certainly possible to do, but I would hope not necessary.

> can the initializer 'manually' call the code which normally harvest
> the RectangleOverlay parameter later on ?

Sure, you can always code in whatever logic you want to the plugin
initializer method. But again, hopefully not necessary in this case.

> even after some reading of the tutorials and the scijava source code
> around org.scijava.command.CommandInfo my understanding of how the
> plugin initialisation works is still poor.

I am sorry—the tutorials need to be improved. What sort of tutorial do you
think would aid your understanding here? The "execute-commands" and
"custom-preprocessor-plugin" tutorials are probably touch on these topics
most closely, although neither provides a real overview of the
pre-/post-processing chain in conjunction with module execution.

> Would it make sense to distinguish (by an annotation ?) parameters
> that are to be initialized from the context (i.e. services, active
> image, roi etc), and whose lack should be immediately fatal to the
> plugin (no UI harvesting, and in exchange can be assumed final for the
> rest of the command execution), from parameters that, if they cannot
> be populated from already available data, should be harvested through
> a dialog (and may change several times) ?

Potentially, yes. Feel free to comment on the issue on GitHub!

Regards,
Curtis

[1]
https://github.com/imagej/imagej-common/blob/imagej-common-0.15.1/src/main/java/net/imagej/display/process/ActiveOverlayPreprocessor.java#L57

[2]
https://github.com/scijava/scijava-common/blob/scijava-common-2.44.2/src/main/java/org/scijava/module/process/InitPreprocessor.java#L49

[3] http://imagej.net/Bug_reporting_best_practices

[4] http://stackoverflow.com/help/mcve


On Mon, Aug 24, 2015 at 9:07 AM, Adrian Daerr <
adrian.daerr at univ-paris-diderot.fr> wrote:

> Hi Curtis,
>
> I have parameters a, b, c whose initialisation depend on a common
>>> calculation (depending on the image gotten through a previous
>>> @Parameter ImagePlus imp): can I do this calculation in the
>>> initialiser for the first parameter a, and then in the initialisers of b
>>> and c rely on the fact that the calculation was already done ?
>>>
>>
>> Perhaps simplest at the moment would be to give your command a global
>> initializer -- i.e., set the initializer method in the
>> @Plugin annotation itself, rather than on specific parameters.
>> The ImagePlus will be populated by a preprocessor _before_ the
>> initialize method is called, so when your global initializer gets
>> called you will already have access to the ImagePlus.
>>
>
> Thanks for the suggestion, which almost does the job, except that the
> initialization also depends on a parameter
>
> @Parameter(persist = false) private RectangleOverlay roi;
>
> which appears to be populated only after the initializer is called (its
> value is null in the initializer and valid in the run() method).
>
> I am not sure how to solve this: do I have to write a Preprocessor of some
> sorts, or can the initializer 'manually' call the code which normally
> harvest the RectangleOverlay parameter later on ? Somehow the fact that
> ImagePlus is populated by a Preprocessor but RectangleOverlay isn't, seems
> linked to issues that I mentionned in another post[1], but even after some
> reading of the tutorials and the scijava source code around
> org.scijava.command.CommandInfo my understanding of how the plugin
> initialisation works is still poor.
>
> [1]
> (e.g. that the Overlay appears in the harvesting dialog, or that an
> Exception is thrown because of the overlay after command execution)
>
> http://imagej-devel.54429.x6.nabble.com/Masking-Parameter-from-GUI-harvesting-td1098.html
>
> But again, scijava/scijava-common#181 is very relevant here.
>>
>
> Would it make sense to distinguish (by an annotation ?) parameters that
> are to be initialized from the context (i.e. services, active image, roi
> etc), and whose lack should be immediately fatal to the plugin (no UI
> harvesting, and in exchange can be assumed final for the rest of the
> command execution), from parameters that, if they cannot be populated from
> already available data, should be harvested through a dialog (and may
> change several times) ?
>
> cheers,
> Adrian
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://imagej.net/pipermail/imagej-devel/attachments/20150824/8476353a/attachment.html>