<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body 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<br>
<br>
<br>
On 10/6/2010 6:02 PM, Curtis Rueden wrote:
<blockquote
cite="mid:AANLkTinvB4PR=QHPztKCeF7FCNAYwL9rm-3mrLM=2iWC@mail.gmail.com"
type="cite">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 moz-do-not-send="true"
href="https://docs.google.com/document/pub?id=13zVORIFldha5xT8C3wUPLPGr_ok30rh9whLrEsxYA_s">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 moz-do-not-send="true"
href="http://imagejdev.org">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>
<pre wrap="">
<fieldset class="mimeAttachmentHeader"></fieldset>
_______________________________________________
ImageJ-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:ImageJ-devel@imagejdev.org">ImageJ-devel@imagejdev.org</a>
<a class="moz-txt-link-freetext" href="http://imagejdev.org/mailman/listinfo/imagej-devel">http://imagejdev.org/mailman/listinfo/imagej-devel</a>
</pre>
</blockquote>
<br>
</body>
</html>