<div>Hi Lee,<br><br>Thanks for your feedback!<br><br></div><blockquote style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;" class="gmail_quote"><b>"Each plugin pushes the result forward in the chain using an
image dispatcher"</b><br></blockquote>
<br>This was an idea that Aivar was trying to communicate to the rest of us, which I captured very badly in the notes. So unfortunately I am unable to elaborate further. As we continue to discuss the plugin architecture, I am sure it will come up again.<br>
<br><blockquote style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;" class="gmail_quote">I'd recommend CellProfiler's approach and note that @parameter for
images could let any UI, along with the user, determine which images
are associated with which arguments. A UI should suggest any
previous output image as a possible input image for a later stage.
For interactive ImageJ, this is a list of whatever images are open,
for a pipelined or batch model, this is a list of the outputs of
previous pipeline steps.<br></blockquote>
<br>This approach makes a lot of sense to me.<br><br><blockquote style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;" class="gmail_quote">Is there any mechanism that lets a plugin validate the
consistency of its arguments? For instance, a certain
combination of options may not make sense - most typical case
would be a minimum and maximum numeric value with the maximum
larger than the minimum.<br></blockquote><br>Nothing yet. At the moment the plugin itself would need to throw an exception or something in the run method.<br><br>It would be better for the interface to have a method for checking whether the current combination of values is valid. Ideally, it would return some sort of data structure indicating, for each parameter, whether it is valid, and if not, an explanatory message indicating why not. If we had that, the UI code could do first class interactive input validation on the fly, a la many modern web forms, with e.g. a little red X and error message next to each invalid entry.<br>
<br><blockquote style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;" class="gmail_quote">Related, some @parameters will be superfluous under some
circumstances: as an example, CellProfiler's mixture of
gaussians thresholding method asks "what percentage of the
image is foreground?", but the Otsu thresholding method does
not. CellProfiler does this by asking the module for the
settings to display (and the user doesn't have to implement
the method in which case all are displayed). How would such a
method in ImageJ name the parameters to display? (string
matching the field name? Tags in @parameters matching a string
array returned by the method?<br></blockquote>
<br>Hmm, sounds tricky. Maybe it work similarly to the idea above for validation, where an interface method exists that reports, for each parameter, whether it is currently relevant based on the values of other parameters. A nice demo for this functionality might be as simple as an "configure advanced options" checkbox that opens up a bunch more options. When the box is unchecked, the advanced options all disappear.<br>
<br>Of course, allowing options to be grouped together would ease some of the declarative burden, since you could group all the advanced options into an explicit "advanced options" category.<br><br>Johannes, have you considered any of these ideas?<br>
<br><blockquote style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;" class="gmail_quote"><b>How to specify choices</b>? For instance, our Otsu
thresholding method takes 2 or 3 classes or maximizes the
inter-class variance or entropy. (and there are about 8
thresholding algorithms to choose from other than Otsu). I would
recommend a "choices" attribute in @parameter. I am hoping that
you all can make the architecturally elegant choice of how to
link an ordered array of strings to the attribute.<br></blockquote>
<br>Right, the idea is to limit the valid selections to an enumeration. From a UI
perspective we would use a Swing JComboBox, AWT Choice, or similar. Rick was working on it, and an initial version was commited:<br><br> <a href="http://dev.imagejdev.org/trac/imagej/changeset/1439">http://dev.imagejdev.org/trac/imagej/changeset/1439</a><br>
<br>Not perfect, but hopefully it does the job for the time being. Of course, every time we make improvements like this, the CellProfiler code also has to change to support it...<br><br><blockquote style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;" class="gmail_quote">
Help annotations in @parameter - user-visible explanations of
the effect of each parameter. CellProfiler uses a bastardized
HTML here (limitations of our HTML control).<br></blockquote><br>Yep, good idea.<br><br><blockquote style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;" class="gmail_quote">
"Nudge": the controller can nudge the view, possibly does not
need to nudge the model. UIs can be slow, in CellProfiler, the
nudge is pretty coarse: "View, completely reconstruct yourself".<br></blockquote><br>Right, that is the simplest possible update call, and is usually good/fast enough. We can think about edge cases where more performance is needed later.<br>
<br><blockquote style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;" class="gmail_quote">Maybe think of ways that plugin developers can add both controller
and display elements and reference them from their plugin - the
developer's package registers controller and display names that are
used by the plugin. This would encourage contribution of generic
controller and display code that would be reusable instead of buried
in a single plugin.<br></blockquote><br>Right, I agree that this is the sort of thing we should be striving to do.<br><br><blockquote style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;" class="gmail_quote">
<b>Action items</b><br><b>
</b><br><b>
</b>Lee: CellProfiler demo<br></blockquote><br>It is still in my queue to review the work you have done, as well as the poster, and the paper (the latter before tomorrow morning...).<br><br>-Curtis<br><br><div class="gmail_quote">
On Thu, Oct 7, 2010 at 8:40 AM, Lee Kamentsky <span dir="ltr"><<a href="mailto:leek@broadinstitute.org" target="_blank">leek@broadinstitute.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div bgcolor="#ffffff" text="#000000">
My notes on your notes - I'm not wedded to any of the positions
taken below, so if yours differ, try to convince me otherwise:<br>
<br>
<b>"Each plugin pushes the result forward in the chain using an
image dispatcher"</b><br>
I'd recommend CellProfiler's approach and note that @parameter for
images could let any UI, along with the user, determine which images
are associated with which arguments. A UI should suggest any
previous output image as a possible input image for a later stage.
For interactive ImageJ, this is a list of whatever images are open,
for a pipelined or batch model, this is a list of the outputs of
previous pipeline steps.<br>
<br>
<b>View: 8 GenericDialog<br>
</b>
<ul>
<li>Is there any mechanism that lets a plugin validate the
consistency of its arguments? For instance, a certain
combination of options may not make sense - most typical case
would be a minimum and maximum numeric value with the maximum
larger than the minimum.</li>
<ul>
<li>Related, some @parameters will be superfluous under some
circumstances: as an example, CellProfiler's mixture of
gaussians thresholding method asks "what percentage of the
image is foreground?", but the Otsu thresholding method does
not. CellProfiler does this by asking the module for the
settings to display (and the user doesn't have to implement
the method in which case all are displayed). How would such a
method in ImageJ name the parameters to display? (string
matching the field name? Tags in @parameters matching a string
array returned by the method?<br>
</li>
</ul>
<li><b>How to specify choices</b>? For instance, our Otsu
thresholding method takes 2 or 3 classes or maximizes the
inter-class variance or entropy. (and there are about 8
thresholding algorithms to choose from other than Otsu). I would
recommend a "choices" attribute in @parameter. I am hoping that
you all can make the architecturally elegant choice of how to
link an ordered array of strings to the attribute.<br>
</li>
<li>Help annotations in @parameter - user-visible explanations of
the effect of each parameter. CellProfiler uses a bastardized
HTML here (limitations of our HTML control).</li>
<li>"Nudge": the controller can nudge the view, possibly does not
need to nudge the model. UIs can be slow, in CellProfiler, the
nudge is pretty coarse: "View, completely reconstruct yourself".</li>
</ul>
<b>Display plugin architecture</b><br>
My prejudice here is to find ways to be clever and keep UI out of
the plugin. The trick is to imagine the plugin as being unable to
concieve of the concept of UI and you have to ask the stupid thing
questions that get past its lack of imagination: "Which of your
parameters are relevant for your operation?" = "what parameters
should be displayed on screen". If the plugin hankers to display
something, maybe that's an output parameter and maybe there are
hints as to how it might be displayed, but little more than that:
histogram of a vector of values, scattergram of pairs of values. I
have my personal reasons for these choices (make it work with
CellProfiler), but the result of these choices is an architecture
that will not lock you into display particulars, will regularize the
appearance and interactions across plugins and will give plugin
developers easy to use tools to do the things they need to do.<br>
<br>
Be extremely clever here - it can be a game, how dumb can you make a
plugin? A plugin wants the user to select points or regions or wants
to draw on an image - the drawing, etc, is an input parameter to the
algorithm and it isn't the plugin's job to control the interaction.<br>
<br>
Maybe think of ways that plugin developers can add both controller
and display elements and reference them from their plugin - the
developer's package registers controller and display names that are
used by the plugin. This would encourage contribution of generic
controller and display code that would be reusable instead of buried
in a single plugin.<br>
<br>
<b>Demo of CellProfiler<br>
<br>
</b>I think Curtis has either the binary or a link to one - trunk
CellProfiler build that is demoable for Tubeness. <b>Grant</b> is
looking over my mods to Tubeness - <b>Johannes</b>, you are a
Tubeness author, my mods to it are attached and you are welcome to
correct my mistakes, also if you have any other favorite plugins
that you want to mod or have me mod, I'd love that.<br>
<br>
<b>Action items<br>
<br>
</b>Lee: CellProfiler demo<div><div></div><div><br>
<br>
<br>
On 10/6/2010 6:02 PM, Curtis Rueden wrote:
</div></div><blockquote type="cite"><div><div></div><div>Hi everyone,<br>
<br>
A few of us met for several hours today to discuss some design
issues for ImageJ 2.0. The original goal of the meeting was to
begin defining a new core class hierarchy corresponding to many of
ImageJ's historically most central classes: e.g., ImagePlus,
ImageStack, ImageProcessor. However, we discussed several other
architectural issues as well. I tried to take notes but they ended
up being very terse. Nonetheless, I wanted to mention their
availability at:<br>
<br>
<a href="https://docs.google.com/document/pub?id=13zVORIFldha5xT8C3wUPLPGr_ok30rh9whLrEsxYA_s" target="_blank">https://docs.google.com/document/pub?id=13zVORIFldha5xT8C3wUPLPGr_ok30rh9whLrEsxYA_s</a><br>
<br>
There are not really any detailed class and/or interface
definitions yet—when the design is that far along we will post
details, diagrams, etc. to the <a href="http://imagejdev.org" target="_blank">imagejdev.org</a> web site. But for
the moment we are focusing on some concrete milestones within the
existing ImageJ v1.x codebase, to present at the ImageJ conference
later this month.<br>
<br>
-Curtis<br>
</div></div><pre><fieldset></fieldset>
_______________________________________________
ImageJ-devel mailing list
<a href="mailto:ImageJ-devel@imagejdev.org" target="_blank">ImageJ-devel@imagejdev.org</a>
<a href="http://imagejdev.org/mailman/listinfo/imagej-devel" target="_blank">http://imagejdev.org/mailman/listinfo/imagej-devel</a>
</pre>
</blockquote>
<br>
</div>
<br>_______________________________________________<br>
ImageJ-devel mailing list<br>
<a href="mailto:ImageJ-devel@imagejdev.org" target="_blank">ImageJ-devel@imagejdev.org</a><br>
<a href="http://imagejdev.org/mailman/listinfo/imagej-devel" target="_blank">http://imagejdev.org/mailman/listinfo/imagej-devel</a><br>
<br></blockquote></div><br>