[ImageJ-devel] Design meeting notes

[Curtis Rueden]

Hi Lee,

Thanks for your feedback!

*"Each plugin pushes the result forward in the chain using an image
> dispatcher"*
>

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.

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.
>

This approach makes a lot of sense to me.

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.
>

Nothing yet. At the moment the plugin itself would need to throw an
exception or something in the run method.

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.

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?
>

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.

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.

Johannes, have you considered any of these ideas?

*How to specify choices*? 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.
>

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:

  http://dev.imagejdev.org/trac/imagej/changeset/1439

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...

Help annotations in @parameter - user-visible explanations of the effect of
> each parameter. CellProfiler uses a bastardized HTML here (limitations of
> our HTML control).
>

Yep, good idea.

"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".
>

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.

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.
>

Right, I agree that this is the sort of thing we should be striving to do.

*Action items*
> * *
> * *Lee: CellProfiler demo
>

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...).

-Curtis

On Thu, Oct 7, 2010 at 8:40 AM, Lee Kamentsky <leek at broadinstitute.org>wrote:

>  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:
>
> *"Each plugin pushes the result forward in the chain using an image
> dispatcher"*
> 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.
>
> *View: 8 GenericDialog
> *
>
>    - 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.
>       - 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?
>        - *How to specify choices*? 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.
>     - Help annotations in @parameter - user-visible explanations of the
>    effect of each parameter. CellProfiler uses a bastardized HTML here
>    (limitations of our HTML control).
>    - "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".
>
> *Display plugin architecture*
> 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.
>
> 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.
>
> 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.
>
> *Demo of CellProfiler
>
> *I think Curtis has either the binary or a link to one - trunk
> CellProfiler build that is demoable for Tubeness. *Grant* is looking over
> my mods to Tubeness - *Johannes*, 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.
>
> *Action items
>
> *Lee: CellProfiler demo
>
>
>
> On 10/6/2010 6:02 PM, Curtis Rueden wrote:
>
> Hi everyone,
>
> 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:
>
>
> https://docs.google.com/document/pub?id=13zVORIFldha5xT8C3wUPLPGr_ok30rh9whLrEsxYA_s
>
> 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 imagejdev.org 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.
>
> -Curtis
>
>
> _______________________________________________
> ImageJ-devel mailing listImageJ-devel at imagejdev.orghttp://imagejdev.org/mailman/listinfo/imagej-devel
>
>
>
> _______________________________________________
> ImageJ-devel mailing list
> ImageJ-devel at imagejdev.org
> http://imagejdev.org/mailman/listinfo/imagej-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://imagej.net/pipermail/imagej-devel/attachments/20101007/48c4c639/attachment.html>