[ImageJ-devel] ImageJ - KNIME Integration: open questions

[Curtis Rueden]

Hi Michael, Christian, Martin,

> I just worked through the "code question" (version, context, ...)
> everything  seems to work again.

Excellent, glad to hear!

> Without a (hacky) checkbox we would end up with simply not calling
> preview() on Previewable commands. Additionally we could also change
> this if we wanted to support previews in the future.

I filed a ticket to remove all "Preview" checkbox parameters:
    http://trac.imagej.net/ticket/1952

> @dynamic command detection => ticket filed

Thanks, Michael! For lurkers, the ticket is:
    http://trac.imagej.net/ticket/1933

> We would definitly provide our help for the creation of such a list
> (at least we could look through the plugins and mark the ones that are
> useful within KNIME) however it might be better to delay this until
> short before the final release (final set of plugins, stable plugin
> system).

Great. I filed a ticket for it, slated for 2.0.0 final release:
    http://trac.imagej.net/ticket/1953

> @service order  => ticket filed

Thanks! That ticket is at:
    http://trac.imagej.net/ticket/1934

And I already fixed it. ;-)

> @dimension selection as discussed between christian and curtis we will
> open a ticket with a better explenation for this issue

Christian did file a ticket for it, which is at:
    http://trac.imagej.net/ticket/1944

It's a doozy, so I classified it as a "feature" and tentatively slated for
2.0.0 final release. We will need it for ImageJ2 to really behave
compatibly with ImageJ1's slice-wise PluginFilters. But it will be a
significant undertaking requiring some thought to get both the API and UI
right.

Thanks again for all the feedback and hard work, guys.

Regards,
Curtis


On Wed, Jul 3, 2013 at 10:23 AM, Michael Zinsmaier <michael.zinsmaier at gmx.de
> wrote:

>  Hi Curtis,
>
> thanks for the reply, I just worked through the "code question" (version,
> context, ...) everything  seems to work again.
> Now for the other issues
>
> @preview checkboxes
>
>  Michael wrote:
>  > Would it be possible to add a flag that surpresses previews checkboxes
> > during dialog building?
>
>  It's tricky because right now, each preview checkbox is an input
> parameter to the command itself. But personally I don't like that approach.
> It is not a "real" input to the command, but rather intended to be toggled
> during input harvesting only. One option might be to label the visibility
> of those parameters as ItemVisibility.INVISIBLE. Then we could add a flag
> somewhere to hide INVISIBLE parameters, maybe.
>
>  But really, I am leaning toward a simpler solution: just remove the
> preview checkboxes, in favor of ImageJ2 *always* doing a preview (and of
> course, KNIP doesn't have to). And if the previews are too slow, we can
> optimize the preview() method to address it, rather than having this hacky
> checkbox like ImageJ1 does.
>
> I think the 2nd approach could be a good solution. Without a (hacky)
> checkbox we would end up with simply not calling preview() on
> Previewable commands. Additionally we could also change this if we wanted
> to support previews in the future.
>
> @interactive commands
>
>  Lee wrote:
>  > I hadn't looked at the interactive commands with regard to
> > CellProfiler. It looks like "buttons" could be interpreted as possible
>  > headless actions that could be performed... at least in some cases.
>
>  Yes, each button generally performs some action, which we should really
> make sure are always exposed as standalone commands (see next paragraph).
> We are going to add logic to make multiple sequential Button widgets render
> as a single button bar in our UI layout. Won't affect you though, Lee,
> since you do your own UI in Python.
>
>  Michael wrote:
> > Why is the threshold  plugin an interactive command?
>
>  Let me explain the motivation here. Anything that extends
> InteractiveCommand is not *intended* to be run in headless mode. Rather, it
> is intended as a sort of "meta-command" that allows you to launch other
> commands. It will be filled with callback methods when various inputs
> change, which should, in a properly designed InteractiveCommand, trigger
> real command executions that are more well-behaved from a headless
> standpoint.
>
>  Anything that extends InteractiveCommand should *not* be flagged with
> "headless = true" since it is not intended for that purpose.
>
>  So in the case of threshold, we need a "real" threshold command that has
> sensible inputs and outputs. Then the command exposed in the ImageJ UI as
> "threshold" is actually "Interactive Threshold" which fires off Threshold
> executions.
>
>  This is not all fully in place, but it is the direction we are going. Sound
> reasonable?
>
>  Lee wrote:
>  > For Threshold, I can see reasons for executing the callbacks for
> > "auto", "apply" and "delete" in a headless context
>
>  The above would also address your comments here, Lee. The interactive
> threshold command would not need to be exposed within CP because those
> buttons would each have a corresponding standalone headless-friendly
> command which *would* be exposed.
>
> In our case the standalone headless commands would end up as KNIME nodes
> and the interactive meta command would be ignored.
> Which should work fine.
>
> I have only one small concern, the headless commands should not become to
> fine granular. Consider for example a filter command that supports
> different neighborhood shapes. A meta command for different filters and a
> headless command for each filter (gaussian, max, ...) is a good solution.
> But an implementation with a headless command for each filter and each
> neighbourhood  (gaussian rectangular, gaussian circular, ...) would be too
> much. However thats in the end up to the command implementor and shouldn't
> be a general problem.
>
>
> @dynamic command detection => ticket filed
>
>  Michael wrote:
> > is there a way to determine if a command is dynamic?
>
>  Other than the hacky instanceof test you are doing, nope. I agree we
> should add API for it to ModuleInfo. Especially because it is possible for
> modules to be dynamic without extending the DynamicCommand class...
>
>  Could you please file a ticket for it on the ImageJ Trac? I just made
> ImageJ Trac accounts for you, Christian & Martin; you should have an
> automated email about it. I know Trac is not ideal (GitHub Issues is nice)
> but we have all our ImageJ tickets in Trac now, migrating everything would
> be very involved, and I don't really want to start splitting between two
> issue trackers. Someday we might move...
>
>
> @plugin jars
>
>   > Are you planing to re-organize the plugins, e.g. such that plugins,
>  > which are interesting for any application reside in their own
> > jar-file?
>
>  This is probably a good idea. However, I agree with Lee that in some
> cases it may not be totally clear-cut [1]. You think splitting ij-commands
> into two JAR files is sufficient? If so, care to send a list of plugins you
> feel are *not* generally useful, and I can split them out?
>
> We would definitly provide our help for the creation of such a list (at
> least we could look through the plugins and mark the ones that are
> useful within KNIME) however it might be better to delay this until short
> before the final release (final set of plugins, stable plugin system).
>
> @service order  => ticket filed
>
>   Michael wrote:
>  > we had to move ModuleService behind  MenuService in the constructor
> > call to avoid a null pointer during initialization
> > (onEvent(ModulesAddedEvent) was called before initialize).
>
>  That is a bug, thanks for reporting. However, moving the module service
> after the menu service will not work because MenuService needs
> CommandService which needs ModuleService.
>
>  What's weird to me is, I am not sure why we don't see this bug when
> running the end-user ImageJ application...
>
>  I have some service initialization changes pending on ImageJ's
> startup-speed branch, which may affect this. So we should debug further
> once that branch is merged. Please feel free to file a Trac ticket for it
> and assign to me.
>
>  Michael wrote:
> > Is there a defined service order?
>
>  The order is defined by two things:
>  1) If a service has an @Parameter dependency on another service, the
> dependency gets initialized first.
> 2) Otherwise, the "priority" property of the @Plugin annotation is used to
> order service initialization.
>
>  > ((So far, we have tons of ideas where we could do more things
> > together. Thank you in advance for answering all these questions ;) ))
>
>    @dimension selection
> as discussed between christian and curtis we will open a ticket with a
> better explenation for this issue
>
>
>
> Thanks again for awnsering our questions
> Regards
>
> Christian, Martin, Michael
>
>
>
> p.s.
>
>
> [1] You know what that easter egg does, right? Don't you *want* to
> generate ASCII images using KNIME??? I know I do!
>
> (-: of course we want. But we don't support getChannelMax/Min atm. so in
> KNIME its only for skilled programmers
>
> ++++++++++++++++++++++++++++++++++++++++++++++++++
> ++++++++++++++++++++++++++++++++++++++++o#++++++++
> +++++++++++++++++++++++++++++++++++++++O##O+++++++
> +++++++++++++++++++++++++++++++++++++o#####o++++++
> ++++++++++++++++++++++++++++++++++++########++++++
> ++++++++++++++++++++++++++++++++++o##########+++++
> +++++++++++++++++++++++++++++++++############+++++
> +++++++++++++++++++++++++++++++o###########o++++++
> ++++++++++++++++++++++++++++++############++++++++
> +++++++++#++++++++++++++++++o###########o+++++++++
> ++++++++###o+++++++++++++++############+++++++++++
> +++++++O####o++++++++++++o###########o++++++++++++
> ++++++o######O++++++++++############++++++++++++++
> +++++o#########+++++++*###########o+++++++++++++++
> ++++++##########+++++############+++++++++++++++++
> +++++++##########o+*###########o++++++++++++++++++
> ++++++++O#####################++++++++++++++++++++
> +++++++++*##################o+++++++++++++++++++++
> ++++++++++o###############O+++++++++++++++++++++++
> +++++++++++o#############o++++++++++++++++++++++++
> +++++++++++++##########O++++++++++++++++++++++++++
> ++++++++++++++########o+++++++++++++++++++++++++++
> +++++++++++++++######+++++++++++++++++++++++++++++
> ++++++++++++++++###o++++++++++++++++++++++++++++++
> ++++++++++++++++o#++++++++++++++++++++++++++++++++
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://imagej.net/pipermail/imagej-devel/attachments/20130715/3e5c4ff2/attachment-0001.html>