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