Rich Client Interface for ImageJ

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Rich Client Interface for ImageJ

Marco LO
Dear Listers,
 
I'm looking into the feasibility to implement an ImageJ rich client interface in Eclipse IDE or RCP.  I checked the ImageJDev a.k.a. ImageJ 2.0 design http://imagejdev.org/design, there is only a planned one based on the NetBeans RCP without a trace on the roadmap.  Threre is an existing Eclipse RCP, Bio7 http://bio7.org/, incorporated ImageJ but only the toolbar, pulldown menus and the main image window are integrated. 
 
As far as I see, there are two options to do the Eclipse interface, either complete the Bio7 implementation or wait for the NetBeans RCP and port it to the Eclipse one.
 
The rich client interface could be very helpful especially if ImageJ is used together with other software like that in Bio7, ecology, or any other displicine.  It would boost efficiency dramatically.  I wonder how we could influence the ImageJDev team to finalize the NetBeans RCP plan or even add Eclipse in the paln given that ImagJ has so much diversified and so wide user bases.
 
What would be your comments?
 
 
 
Reply | Threaded
Open this post in threaded view
|

Re: Rich Client Interface for ImageJ

dscho
Hi Marco,

On Tue, 12 Jul 2011, Marco LO wrote:

> I'm looking into the feasibility to implement an ImageJ rich client
> interface in Eclipse IDE or RCP. I checked the ImageJDev a.k.a. ImageJ
> 2.0 design http://imagejdev.org/design, there is only a planned one
> based on the NetBeans RCP without a trace on the roadmap.

It is called 'envisaje', and a prototype is working as far as I can tell.

> Threre is an existing Eclipse RCP, Bio7 http://bio7.org/, incorporated
> ImageJ but only the toolbar, pulldown menus and the main image window
> are integrated.  As far as I see, there are two options to do the
> Eclipse interface, either complete the Bio7 implementation or wait for
> the NetBeans RCP and port it to the Eclipse one.

There is already some SWT support, no need to wait. But I'd strongly
suggest to subscribe to the ImageJDev mailing list and announce what you
want to do, to avoid unnecessary, duplicate work!

> The rich client interface could be very helpful especially if ImageJ is
> used together with other software like that in Bio7, ecology, or any
> other displicine. It would boost efficiency dramatically.

I look forward to be convinced of that!

> I wonder how we could influence the ImageJDev team to finalize the
> NetBeans RCP plan or even add Eclipse in the paln given that ImagJ has
> so much diversified and so wide user bases.

Please do not lean on the ImageJDev team right now. It is a huge
undertaking to provide a generic foundation to image processing _and_ make
it backwards compatible with ImageJ. And most users will want to have the
user interface they are wont to anyway.

So if you want to have an ImageJ2 frontend based on the Eclipse Rich
Client Platform, I would _strongly_ recommend to discuss this with the
ImageJDev team, but in the end to Do It Yourself.

Ciao,
Johannes
Reply | Threaded
Open this post in threaded view
|

Re: Rich Client Interface for ImageJ

ctrueden
In reply to this post by Marco LO
Hi Marco,

I'm looking into the feasibility to implement an ImageJ rich client
> interface in Eclipse IDE or RCP.  I checked the ImageJDev a.k.a. ImageJ
> 2.0 design http://imagejdev.org/design, there is only a planned one based
> on the NetBeans RCP without a trace on the roadmap.  Threre is an existing
> Eclipse RCP, Bio7 http://bio7.org/, incorporated ImageJ but only the
> toolbar, pulldown menus and the main image window are integrated.
>

The plan for the first release of ImageJ 2.0 is a Swing-based application
that generally replicates the functionality and look/feel of ImageJ1, but
build on top of an entirely new infrastructure. Important aspects of the new
design include:

1) GUI toolkit independence, which affords the development of applications
using your toolkit of choice (AWT, Swing, SWT, Pivot, etc.). We will be
implementing the primary ImageJ user interface in Swing, as well as many
application components for Swing, pure AWT, SWT and Pivot. We will also have
application components intended for headless use. And as time allows, we are
developing barebones/prototype GUIs in AWT, SWT and Pivot as well.

2) To the extent possible, core functionality is provided by plugins. The
IJ2 plugin framework is designed such that inputs and outputs are declared
independent of UI, and processing can be done with no dependence on any
particular widget toolkit.

3) To facilitate usage of IJ2 in environments where AWT is not available
(GWT, Android, etc.), we are striving to keep all usage of AWT out of the
core IJ2 packages. We are using the EventBus (http://eventbus.org/)
publish/subscribe mechanism with our own hierarchy of event classes
including mouse and keyboard events, to eliminate dependence on the
java.awt.event implementation.

Version 2.0 of ImageJ will not be built on a rich client platform, though a
later version might be. We did explore usage of the NetBeans RCP,
specifically building a client codenamed Envisaje, based on Imagine (
http://java.net/projects/imagine/). Pursuing that development further is
mostly an issue of prioritization; our primary goal for the 2.0 release is
compatibility, rather than converting ImageJ into an RCP-based application.

That said, a major goal is for the IJ2 core classes to be embeddable into
any conceivable application, including RCPs. The publish/subscribe event
paradigm enables a highly decoupled design, so it should mostly be a matter
of subscribing to the appropriate events, and reusing the appropriate UI
components, within your application framework. In short, we want IJ2's core
functionality to be easily usable in an RCP context, but not dependent on
it.

At the last ImageJ conference I spoke with Marcel Austenfeld, author of
Bio7, and he has offered to share code and insights into building an Eclipse
RCP version of ImageJ. In the future, we hope it will be easier to maintain
Bio7 against ImageJ2 than it has been with ImageJ1, since it should no
longer be necessary to fork any of the ImageJ class implementations. But it
will be a substantial endeavor to update Bio7 to ImageJ2, so I concur with
Johannes that depending on your level of patience, you may need to "Do It
Yourself" for quickest results.

I suggest waiting until at least the beta period (later this summer) before
getting too invested in IJ2 programming, since the APIs are still evolving.
At that point, we would love to have your feedback on the design, and would
be happy to answer questions and offer guidance on integrating IJ2 with an
RCP application.

Regards,
Curtis Rueden
ImageJDev project lead
http://imagejdev.org/

On Tue, Jul 12, 2011 at 2:45 AM, Marco LO <[hidden email]> wrote:

> Dear Listers,
>
> I'm looking into the feasibility to implement an ImageJ rich client
> interface in Eclipse IDE or RCP.  I checked the ImageJDev a.k.a. ImageJ
> 2.0 design http://imagejdev.org/design, there is only a planned one based
> on the NetBeans RCP without a trace on the roadmap.  Threre is an existing
> Eclipse RCP, Bio7 http://bio7.org/, incorporated ImageJ but only the
> toolbar, pulldown menus and the main image window are integrated.
>
> As far as I see, there are two options to do the Eclipse interface, either
> complete the Bio7 implementation or wait for the NetBeans RCP and port it
> to the Eclipse one.
>
> The rich client interface could be very helpful especially if ImageJ is
> used together with other software like that in Bio7, ecology, or any other
> displicine.  It would boost efficiency dramatically.  I wonder how we could
> influence the ImageJDev team to finalize the NetBeans RCP plan or even add
> Eclipse in the paln given that ImagJ has so much diversified and so wide
> user bases.
>
> What would be your comments?
>
Reply | Threaded
Open this post in threaded view
|

Re: Rich Client Interface for ImageJ

Marcel
In reply to this post by Marco LO
Hello,

......
incorporated ImageJ but only the toolbar, pulldown menus and the main image window are integrated
.......

I wonder, do you speak about the Bio7 Imagej application? I would say that most of the ImageJ functionality has been integrated.

The ImageJ plugin of Bio7 is partially a Swing port of ImageJ which uses the SWT_AWT-bridge to integrate this plugin into a Rich-Client Application.

For the display i decided to use tabs instead of windows. A design decision i made because i think this fits well in a Rich Client Concept (without many windows opened side by side).

In addition here are some features you've missed to mention:

- Many, many of the ImageJ plugins work and automatically extend the Bio7-ImageJ "Plugins" menu (the menu implementation, however, has to be improved in the next releases). Plugins which throw an error can easily be adapted for the Swing interface (only a few have to be changed  a little bit more because of the different design concept).

 -Drag and drop of plugins works (on the toolbar or the tabbed interface).

- Imagej macros can be created and executed.

- Plugins can be created and compiled with the connected and embedded Eclipse compiler (instead of the sun compiler). Since Bio7 1.5 you can also use the Bio7 interface for the creation of plugins.

- Images can be opened side by side in a tabbed interface (a design decision!). Stacks and Hyperstacks can be opened (or converted) in a tab, too.

- Drag and drop of images on the panel works, too.

and....and....

........
The rich client interface could be very helpful especially if ImageJ is used together with other software like that in Bio7, ecology, or any other displicine
………..

That’s why many other applications are integrated into Bio7 not only useful in ecology but also in other disciplines.
With the R interface e.g. it is possible to do all kind of mathematical and statistical calculations (a nice side effect is that you can call Fortran or C code from an R plugin with Java– many of the R plugins e.g. are programmed in c/c++).

Here are some presentations showing the ImageJ interaction with the statistical software R (some of them are a bit old):

http://www.uni-bielefeld.de/biologie/Oekosystembiologie/bio7app/flashtut/selectedpixels.htm
http://www.uni-bielefeld.de/biologie/Oekosystembiologie/bio7app/flashtut/imagetnew.htm
http://www.uni-bielefeld.de/biologie/Oekosystembiologie/bio7app/flashtut/processavis.htm
http://www.uni-bielefeld.de/biologie/Oekosystembiologie/bio7app/flashtut/animaterplot.htm

Cluster ImageJ image data with R

http://www.uni-bielefeld.de/biologie/Oekosystembiologie/bio7app/flashtut/cluster.htm
http://www.uni-bielefeld.de/biologie/Oekosystembiologie/bio7app/flashtut/supervisedimages.htm

Transfer only selected ImageJ pixels to R

http://www.uni-bielefeld.de/biologie/Oekosystembiologie/bio7app/flashtut/selectedpixels.htm

Shape Analysis:

http://www.uni-bielefeld.de/biologie/Oekosystembiologie/bio7app/flashtut/shape_analysis.htm

And here are some presentations about using ImageJ in combination with the Java WorldWind globe (can be combined easily with the spatial analysis capabilities of R)  and the 3d interface of Bio7.

http://www.uni-bielefeld.de/biologie/Oekosystembiologie/bio7app/flashtut/worldwinddynamic.htm
http://www.uni-bielefeld.de/biologie/Oekosystembiologie/bio7app/flashtut/spatialview.htm

For one of the next releases i plan to offer ImageJ updates with the integrated Eclipse p2 Update Manager of Bio7. A standalone Eclipse plugin of ImageJ could also be created (which is not hard to do because the Bio7 ImageJ plugin has it's own independent plugin structure...….but time…..).

At the moment i’m also working on a new Bio7 User Guide which hopefully gives a better overview of the Bio7 functionality and especially the Bio7 ImageJ plugin.
I’m also looking forward for the ImageJ2 release of the ImageJDev team which certainly opens new ways of implementations (time to link the website as well as the Fiji website!).

Here you can find an early draft (http://bio7.org/?page_id=10) as a preview.

I hope this information helps and avoids words like “only” ;-)