Any life in ImageJX?

1 view
Skip to first unread message

wil...@ieee.org

unread,
Jun 6, 2009, 5:23:33 AM6/6/09
to ImageJX, wil...@ieee.org
Hello all,

this group has been *very* quiet recently. In the meantime (as
expected) our internal proposal for an ImageJX initiative did not get
funded. Beyond that I just wondered if there was any interest left in
this issue with anybody else.

Wilhelm

Johan Henriksson

unread,
Jun 7, 2009, 4:13:48 PM6/7/09
to ImageJX
I think there is plenty of interest but taking the step to start
developing is huge. there is light in the end of the tunnel though. my
perspective is that fixing imagej entirely will break backward
compatibility with all plugins, but the plugins are the reason imagej
is still popular (except the lack of alternatives). hence only smaller
fixes are worthwhile. there are two routes:

* The Fiji project (http://pacific.mpi-cbg.de/wiki/index.php/
Main_Page)
if you want to keep using imagej and are fine with fine-tuning, then
maybe you should join this very active community

* The next generation imaging software, such as my own Endrov
(www.endrov.net)
if you want to address core issues such as bad 4d support, metadata
etc then you have to look at entire rewrites. there are several
attempts on the way. I aim to have the first non-beta release of
Endrov out in a 3 months, and it solves all the problems that I have
seen float up in the discussions here.

that about covers everything. if your interest fits any of these
projects then it's better spent time to join than to start yet another
project. it's a serious amount of work to start anew (endrov is 90 000
lines of code and growing)

/Johan

Johannes Schindelin

unread,
Jun 7, 2009, 4:23:07 PM6/7/09
to Johan Henriksson, ImageJX
Hi,

On Sun, 7 Jun 2009, Johan Henriksson wrote:

> I think there is plenty of interest but taking the step to start
> developing is huge. there is light in the end of the tunnel though. my
> perspective is that fixing imagej entirely will break backward
> compatibility with all plugins, but the plugins are the reason imagej is
> still popular (except the lack of alternatives). hence only smaller
> fixes are worthwhile. there are two routes:
>
> * The Fiji project (http://pacific.mpi-cbg.de/wiki/index.php/ Main_Page)
> if you want to keep using imagej and are fine with fine-tuning, then
> maybe you should join this very active community
>
> * The next generation imaging software, such as my own Endrov
> (www.endrov.net) if you want to address core issues such as bad 4d
> support, metadata etc then you have to look at entire rewrites. there
> are several attempts on the way. I aim to have the first non-beta
> release of Endrov out in a 3 months, and it solves all the problems
> that I have seen float up in the discussions here.

There is a thirds option. You _can_ stay backwards-compatible, adding a
new interface to ImageJ _without_ breaking backwards compatibility.

We are just about releasing something like imagescience.jar in Fiji, just
way better:

- it does not break backwards-compatibility (no need to reimplement what
already works),

- it is an interface to image data that makes it easy not to care about
the dimensionality and data type of the images,

- it is efficient, using Java 1.5's generics to the full extent, and

- it does not implement a new GUI with its own set of shortcomings, but
continues to use the GUI people are used from ImageJ (possibly enhancing
it incrementally),

- oh, and it is Open Source (which is way superior than a closed-source
component you have to beg to be enhanced).

Ciao,
Dscho

wil...@ieee.org

unread,
Jun 8, 2009, 10:00:35 AM6/8/09
to ImageJX
Johannes,

this sounds interesting - can you share any more information and/or
give API examples?

Wilhelm


On Jun 7, 10:23 pm, Johannes Schindelin <Johannes.Schinde...@gmx.de>
wrote:
> Dscho- Hide quoted text -
>
> - Show quoted text -

Johannes Schindelin

unread,
Jun 11, 2009, 9:01:42 AM6/11/09
to wil...@ieee.org, ImageJX
Hi,

On Mon, 8 Jun 2009, wil...@ieee.org wrote:

> this sounds interesting - can you share any more information and/or give
> API examples?

As I said: soon.

Ciao,
Johannes

Grant

unread,
Jun 11, 2009, 4:58:02 PM6/11/09
to ImageJX
Hi, all.

I'm excited to hear from Johannes that there is something in the works
there. I'd also like to find out more about it as soon as possible.

Sorry to have been so quiet on my end, but there has been some
activity. As many of you are probably aware, the NIH got a pile of
economic stimulus funds, and there have been some ImageJ-related grant
applications, 2 of which I am aware of. Here at the MBL we applied
for funding to integrate and customize several open-source imaging
systems to support the summer educational courses here, many of which
involve microscopy. We will be utilizing ImageJ, BioFormats, OMERO,
microManager, Endrov, VisBio, and anything else that we find useful.
If we are funded, we hope to act as a site where the community can
collaborate to enhance the interoperability of these systems.
The LOCI group at Univ. of Wisconsin has submitted a considerably more
ambitious application that directly addresses extending the design of
ImageJ to address many of the issues that have been talked about
here. I'll leave it to Curtis Rueden to reveal the details, should he
wish to. We won't know about the funding decisions until August, at
the earliest.

So, there is significant *potential* for efforts in this direction to
breath more life into ImageJX, or what ever this is called. Whatever
the outcome, I'll be continuing to work on this as time allows and I
look forward to more interaction.

Cheers,
Grant Harris, MBL

Curtis Rueden

unread,
Jun 12, 2009, 4:21:25 PM6/12/09
to ImageJX
Hi Grant et al,

> The LOCI group at Univ. of Wisconsin has submitted a considerably more
> ambitious application that directly addresses extending the design of
> ImageJ to address many of the issues that have been talked about
> here. I'll leave it to Curtis Rueden to reveal the details, should he
> wish to. We won't know about the funding decisions until August, at
> the earliest.

As Grant said, we will not know for a while about any funding
decisions. It is also worth mentioning that these GO grants are
extremely competitive (funding in the 1% range), so even though I
think our proposal is very strong, the chances of being funded are
low. Even if not funded, the proposal may help springboard toward
additional funding avenues in the future.

-Curtis

Dimiter

unread,
Jun 25, 2009, 4:20:12 AM6/25/09
to ImageJX
Hi to all,
Take a look at the JabRef plugin extension model:

http://jabref.wiki.sourceforge.net/Getting+started+with+JabRef+plugin+development

I think it's pretty much what we can ask for.

Dimiter
============================================

Getting started with JabRef plugin development

Plugins are a way to extend JabRef with additional functionality.
Plugins can be distributed separately from JabRef itself, and are
loaded when you start JabRef.

1. What must a plugin contain?

A plugin must be packaged as a Jar file. The Jar file must contain in
its root a file called plugin.xml. This XML file refers to a specific
Java class, and this class and all its supporting classes and
resources must be included in the Jar.

2. Extension points

JabRef's plugins system offers a set of Extension points, and each
plugin should attach to one or more of these. Each Extension point is
in Java terms a specific interface that the plugin must implement, and
in practical terms is a type of functionality that can be added. If
you take a look at JabRef's source code tree, you will find the
definition of all extension points in the file src/plugins/
net.sf.jabref.core/plugin.xml, and these definitions also include all
parameters that can or must be defined for plugins attaching to the
extension points.

ImportFormat

This extension point lets you add an import filter to JabRef,
appearing in the file type dropdown menu in the file dialog when
importing.

ExportFormat


EntryFetcher

This extension point lets you add a so-called Entry fetcher to JabRef,
appearing under the Web search menu.

PushToApplication

This extension points lets you add options to insert selected entries
into external applications, such as is already available for LyX,
WinEdt and other applications.

LayoutFormatter

An example plugin

We will in the following develop a simple plugin as an example of how
it can be done. We will build the plugin with Apache Ant.

The plugin will be of the PushToApplication type, offering to call a
configurable shell/dos command embedding the list of BibTeX keys for
the selected entries. Such a plugin can be configured to duplicate
several of the existing push-to-features (e.g. Emacs, Lyx and Vim).

The Java source of the plugin will be contained in the file
PushToX.java. This file defines the class example.PushToX, which
implements the interface net.sf.jabref.external.PushToApplication. We
will get back to the contents of the Java source later on. First we
will take a look at the plugin.xml file.

The plugin.xml file

The plugin.xml file will look like this: plugin.xml

Apart from the header, the XML file contains three important parts:

<requires>
<import plugin-id="net.sf.jabref.core"/>
</requires>

This part is necessary because all plugins extend the so-called core
plugin which is defined by JabRef's own plugin file.

<runtime>
<library type="code" path="classes/" id="code"/>
</runtime>

This part defines where to find the plugin's code. In our plugin there
are no resources apart from the code, and the <library> tag defines
that the plugin code resides in the classes directory within the Jar
file. Specifically, this means that the example.PushToX class is found
in the file classes/example/PushToX.class within the Jar file.

<extension id="PushToX" plugin-id="net.sf.jabref.core" point-
id="PushToApplication">
<parameter id="pushToApp" value="example.PushToX" />
<parameter id="name" value="Push to external application" />
<parameter id="description" value="Configurable plugin for pushing
citations to external application" />
</extension>

This part defines how the plugin attaches to the extension point. The
first line gives our plugin the id PushToX, and states that it extends
the core plugin at the extension point PushToApplication.

The second line defines the parameter pushToApp which needs to be
given a value for all PushToApplication plugins. The parameter should
point to the name of the class implementing the required interface,
namely net.sf.jabref.external.PushToApplication.

The third and fourth lines give the name and a description of the
plugin.

======================================


On Jun 7, 10:23 pm, Johannes Schindelin <Johannes.Schinde...@gmx.de>
wrote:

Grant

unread,
Jul 8, 2009, 2:16:23 PM7/8/09
to ImageJX
Johannes --
We're waiting! We're waiting!
Anything new on your project?
Cheers,
- Grant

On Jun 11, 9:01 am, Johannes Schindelin <Johannes.Schinde...@gmx.de>
wrote:

wil...@ieee.org

unread,
Jul 21, 2009, 1:50:47 PM7/21/09
to ImageJX
Yes, but I still hope that the general discussion will not be halted
by a single announcement (which should eventually materialize though).

Wilhelm
> > Johannes- Hide quoted text -

Johan Henriksson

unread,
Jul 22, 2009, 10:03:26 AM7/22/09
to ima...@googlegroups.com
since I think the software is coming, I don't think it's a very clever idea to start up yet one more software development effort. but I think this community can do a lot just in terms of developing a goal of what our future should be able to deal with (the technical requirements previously posted have all been implemented here). what I would like to see:

* most importantly, use cases: "I want to do X with Y to obtain Z". a very detailed list, it should be possible to verify that it is possible with a particular software. this would speed up development a lot
* a list of publications describing the state of the art of all quantitative methods, algorithms and equations
* a compiled set of images that can be used to benchmark algorithms and software

on a side-note, this is on the way now finally: http://cirl.memphis.edu/cosmos/
in case anyone is into deconvolution

/Johan
--
-----------------------------------------------------------
Johan Henriksson
PhD student, Karolinska Institutet
http://mahogny.areta.org  http://www.endrov.net

Curtis Rueden

unread,
Jul 22, 2009, 1:23:56 PM7/22/09
to ImageJX
Hi Johan et al,

> * most importantly, use cases: "I want to do X with Y to obtain Z". a very
> detailed list, it should be possible to verify that it is possible with a
> particular software. this would speed up development a lot

In some ways, that's what the ImageJ list accomplishes. People write
all the time asking how to do X with Y to obtain Z, and they usually
get responses. If we were to compile a more formal list, we would need
a list of people (us?) who contribute items, and another list of
people (also us?) who review which items on the list are possible/
implemented/done, and how to proceed with items that need work.

Also, it is worth mentioning that often with ImageJ the answer to "Can
I do X with Y to obtain Z" is "Yes, but... you have to write a plugin/
macro/etc." For many use cases, that is a fine answer. But for very
common cases, we obviously want to make it simpler than that.

> * a list of publications describing the state of the art of all quantitative
> methods, algorithms and equations

The ITK (Insight Toolkit) community has attempted to tackle this
problem using their Insight Journal: http://www.insight-journal.org/

This open-access journal is the central place to submit papers about
new or improved analysis algorithms, including source code, that uses
ITK. The focus thus far has been on medical imaging, but there is a
growing effort to make ITK more usable for the microscopy community.
There has also been a lot of recent work on wrapping ITK (written in C+
+) to be usable in Python and Java, so ImageJ/ITK integration is much
more feasible now.

> * a compiled set of images that can be used to benchmark algorithms and
> software

Good idea. ImageJ has a nice start with its "Open samples" list,
though it would be nice if it were tweakable with a configuration file
somewhere.

-Curtis

Johannes Schindelin

unread,
Jul 22, 2009, 1:28:58 PM7/22/09
to Curtis Rueden, ImageJX
Hi,

On Wed, 22 Jul 2009, Curtis Rueden wrote:

> On Jul 22, 9:03 am, Johan Henriksson <he.jo...@gmail.com> wrote:
>
> > On Tue, Jul 21, 2009 at 7:50 PM, wil...@ieee.org <wil...@ieee.org> wrote:
> >
> > > Yes, but I still hope that the general discussion will not be halted
> > > by a single announcement (which should eventually materialize though).
> >

> > > On Jul 8, 8:16 pm, Grant <ghar...@mbl.edu> wrote:
> > > > Johannes --
> > > > We're waiting!  We're waiting!
> > > > Anything new on your project?

Oh, I missed that mail.

The problem on this side is time.

Ciao,
Dscho

Johan Henriksson

unread,
Jul 23, 2009, 2:30:02 AM7/23/09
to ima...@googlegroups.com
On Wed, Jul 22, 2009 at 7:23 PM, Curtis Rueden <ctrued...@gmail.com> wrote:

Hi Johan et al,

> * most importantly, use cases: "I want to do X with Y to obtain Z". a very
> detailed list, it should be possible to verify that it is possible with a
> particular software. this would speed up development a lot

In some ways, that's what the ImageJ list accomplishes. People write
all the time asking how to do X with Y to obtain Z, and they usually
get responses. If we were to compile a more formal list, we would need
a list of people (us?) who contribute items, and another list of
people (also us?) who review which items on the list are possible/
implemented/done, and how to proceed with items that need work.
 
I don't think it need be more formal than a wiki; some people need just take
care of cleaning up once in a while though. since we have several projects,
some overlapping, it's not as easy as just keeping bug track and tick of the
items. we could just add comments and/or tutorial links once anyone has written a tool.



Also, it is worth mentioning that often with ImageJ the answer to "Can
I do X with Y to obtain Z" is "Yes, but... you have to write a plugin/
macro/etc." For many use cases, that is a fine answer. But for very
common cases, we obviously want to make it simpler than that.

indeed, at the same time we have to spend our resources to maximize rate of
interest. a voting system would be optimal. is there a bugtracker allowing editing
of posts and with voting?


The ITK (Insight Toolkit) community has attempted to tackle this
problem using their Insight Journal: http://www.insight-journal.org/

thanks for the link!
 

> * a compiled set of images that can be used to benchmark algorithms and
> software

Good idea. ImageJ has a nice start with its "Open samples" list,
though it would be nice if it were tweakable with a configuration file
somewhere.


indeed a good start. TODO regarding the files:
* it's rather low on 3d and 3d+t recordings
* no weird formats (zips)
* license information should be clarified
* a simple formalized .xml metadata file for each image, so any software can autodetect what should be under "open samples"

I think this could be started up not too heavy duty; we just need some web
space and someone to hand out accounts. I could contribute this.

so who's on? does anyone have a diverse set of images to contribute? I have
lots of images, but all of the same thing :(

/Johan

--
-----------------------------------------------------------
Johan Henriksson

wil...@ieee.org

unread,
Jul 23, 2009, 5:44:13 AM7/23/09
to ImageJX
These may all be nice ideas but (as Curtis suggested) there are better
places to discuss them. This particular group is supposed to collect
ideas for a potential redesign of the ImageJ API (if I remember
right).

Wilhelm


On Jul 23, 8:30 am, Johan Henriksson <he.jo...@gmail.com> wrote:

Dimiter Prodanov

unread,
Jul 24, 2009, 5:18:36 AM7/24/09
to ima...@googlegroups.com
Hi to All,

I see that the discussion is again restarted. So I propose to collect
the ideas/options in a design-like document in Google Doc rather that
shooting back and forth e-mails.

D

Johannes Schindelin

unread,
Jul 24, 2009, 5:52:09 AM7/24/09
to Dimiter Prodanov, ima...@googlegroups.com
Hi,

On Fri, 24 Jul 2009, Dimiter Prodanov wrote:

> I see that the discussion is again restarted. So I propose to collect
> the ideas/options in a design-like document in Google Doc rather that
> shooting back and forth e-mails.

TBH I could not care less about the mode of writing said document, and
absent any content, I cannot see why emails should not be good enough.

I am much more interested in _content_. So far, only Curtis provided
some concrete ideas.

(Well, if you ignore my _negative_ wish: I sincerely believe that breaking
backwards-compatibility will cost you _dearly_ in terms of users -- not
only numbers, but also support by them -- but then, I am convinced that
breaking backwards-compatibility is not necessary at all)

Ciao,
Dscho

Dimiter

unread,
Jul 24, 2009, 7:41:41 AM7/24/09
to ImageJX
This is exactly the point. I suggest that somebody has to propose
initial content.

So far we have only the proposal

"Interface is all" which I think is going to the extreme.

I propose an alternative: to define (up to several) abstract classes
that will implement the PlugIn and PlugInFilter.

What I also miss is :
1) a generic mechanism to handle key bindings and to reallocate key
bindings from other plugins.
2) help mechanism

BTW I already started actively using my abstract plugin class APlugin
in my projects.

Curtis Rueden

unread,
Jul 30, 2009, 2:50:17 PM7/30/09
to ima...@googlegroups.com
We will hear back about our GO grant proposal very soon (early August, I think). Once we know how it fared, I will reply back to the list. Regarding "concrete ideas," I spelled out some technical aims in the proposal, which I would be glad to reiterate here. Ultimately though, the only way to get completely precise will be to start actually trying the proposed changes on the codebase, and seeing what the consequences are.

Johannes Schindelin

unread,
Aug 5, 2009, 2:48:20 AM8/5/09
to Curtis Rueden, ima...@googlegroups.com
Hi,

On Thu, 30 Jul 2009, Curtis Rueden wrote:

> We will hear back about our GO grant proposal very soon (early August, I
> think). Once we know how it fared, I will reply back to the list.

That's wonderful!

> Regarding "concrete ideas," I spelled out some technical aims in the
> proposal, which I would be glad to reiterate here. Ultimately though,
> the only way to get completely precise will be to start actually trying
> the proposed changes on the codebase, and seeing what the consequences
> are.

FWIW we have something _preliminary_ -- without documentation or code
samples, and not even complete yet, in our 'imagecontainer1' branch in
fiji.git.

The idea is to have Type instances that wrap the data type (by "wrap" I
do not mean that they extend java.lang.Integer and friends -- that would
be horrible in terms of memory complexity! -- but rather that those Type
instances can hold a value and contain methods to do basic arithmetic
with the values), Container instances that wrap whatever memory/disk
layout your image (hyper-)stack wants to have, and Cursor instances that
traverse the containers.

A (very small) example: this will create a 2x2x2 float image and fill it
with increasing values:

FloatTypeImage img =
factoryFloat.createImage(new int[]{2, 2, 2},
"2D Float Test image" );

Cursor<FloatType> c = img.createCursor();

int i = 1;
while ( c.hasNext() )
{
c.fwd();
c.getType().set( i );
i++;
}

ImageJFunctions.displayAsVirtualStack( img,
ImageJFunctions.GRAY32 ).show();

We will have to fiddle with the interfaces, of course, and do some
profiling (as it appears that at least in a few cases, there are a few
percent between the runtime of our container-based algorithm and an
implementation using basic types).

The idea, of course, is to allow implementations of algorithms that are
independent of the data type, but which are still readable (even more so,
I would contend, as all the cruft of nested loops with different indices
that can be confused, and calculations from pixel coordinates into array
indices that can be wrong) and fast.

Ciao,
Johannes

wil...@ieee.org

unread,
Aug 14, 2009, 2:18:48 AM8/14/09
to ImageJX, johannes....@gmx.de
Johannes,

is there any way to browse the corresponding source code without
downloading Fiji?

Thanks,
Wilhelm



On Aug 5, 8:48 am, Johannes Schindelin <Johannes.Schinde...@gmx.de>
wrote:

Stephan Saalfeld

unread,
Aug 14, 2009, 3:55:47 AM8/14/09
to ima...@googlegroups.com

Johannes Schindelin

unread,
Aug 14, 2009, 4:42:04 AM8/14/09
to wil...@ieee.org, ImageJX
Hi,

On Thu, 13 Aug 2009, wil...@ieee.org wrote:

> is there any way to browse the corresponding source code without
> downloading Fiji?

Yes. As mentioned on the Wiki (third paragraph, the link to the
"repository"), following "fiji.git" into the "imagecontainer1" branch:

http://pacific.mpi-cbg.de/cgi-bin/gitweb.cgi?p=fiji.git;a=shortlog;h=refs/heads/imagecontainer1

But as with all source code, you have an easier time figuring out what is
going on if you download it and play with it.

Note that I picked up work on it yesterday, but due to technical reasons
am no able to push the changes to pacific.

Ciao,
Dscho

Stephan Saalfeld

unread,
Aug 14, 2009, 4:47:06 AM8/14/09
to ima...@googlegroups.com
Dear Wilhelm,

let me try to explain the target of this attempt in some more words.

For C++, there exist e few attempts (GIL, Vigra, ITK) to generalize
image processing libraries using concepts lent by the STL such as:

* generic types (templates)
* separation of access strategy, types and storage strategy

By that, one can achieve efficiency improvements for data access (e.g.
iteration through all pixels for enhancing the contrast doesn't require
to know where you are in the image nor the order of iteration) and, if
carefully implemented, generic algorithms (filters, transformations)
that do not care about image types and dimensionality and thus do not
have to be reimplemented ever and ever again.

There are some extensions to the STL-like concepts required when it
comes to image processing (because images are n-dimensional functions
and not just containers) which are:

* n-dimensionality,
* interpolated access to pixel values
* intelligent storage strategies (e.g. image data is large particularly
if it comes to higher dimensions and thus no image should be required
to fit into RAM in full)
* connection of iterators (we call them cursors) by operators and
transformations

Having this, filters can be expressed having two images and two (or
more) iterators connected by a pixel-operator. Transformations would be
just two images with two iterators connected by a transforming function.
Even screen-display is then just a filter (that combines the scalar
values alongside one of the dimensions into RGB or grey) and a
transformation (R^2->R^n) that defines the location of each screen pixel
in the actual image.

But, and here comes the tricky part, Java the language does not have the
flexible language features required to express this kind of generality
in the most efficient way (which is: make the compiler generate the most
efficient code on compile time). Anyway, at least something should be
possible taking into account that there are generics (at least for
non-basic types) and JIT and inheritance and interfaces.

What you see here is a draft, a proof of concept, that realizes some of
these features with an n-dimensional float-container being the exemplary
back-end and a virtual stack front-end whose aim is to display it.

For the applied sciences, this kind of very basic conceptual work is
usually not of immediate interest. That's why things move so slowly and
would need a different kind of funding (for computer scientists working
on just it) than what we have now (none).

Any comments very appreciated.

Best,
Stephan

wil...@ieee.org

unread,
Aug 14, 2009, 5:07:43 AM8/14/09
to ImageJX, saal...@mpi-cbg.de
Stephan,

thanks for the pointer and the outline of your project. I am on
vacation right now but comments will follow ...

Wilhelm
> >http://pacific.mpi-cbg.de/cgi-bin/gitweb.cgi?p=fiji.git;a=tree;h=refs...

Dimiter Prodanov

unread,
Aug 14, 2009, 8:26:16 AM8/14/09
to ima...@googlegroups.com
Hi Stephan,

Which project do you comment now?
the imagecontainer or something else?

D

Johannes Schindelin

unread,
Aug 14, 2009, 12:53:36 PM8/14/09
to Dimiter Prodanov, ima...@googlegroups.com
Hi,

On Fri, 14 Aug 2009, Dimiter Prodanov wrote:

> Hi Stephan,

He probably missed your mail, as you did not Cc: or To: it to him.

> Which project do you comment now?
> the imagecontainer or something else?

Obviously about the imagecontainer.

Please note that this is in _heavy_ flux; it does not even compile at the
moment, as Stephan and me worked on it, and he decided to take a
completely different course from what I originally envisaged for the
ImagePlus adaption.

So maybe the best would be to wait a few days until I cleaned up the stuff
for proper inclusion into Fiji and started writing an introduction on the
Fiji Wiki.

Of course, the project is almost independent of the current ImageJ
version; that was the whole idea, right? It's just a thin wrapper on top
of ImagePlus just so we do not need to lose existing customers. Because a
project without customers is like a fish without bike.

Ciao,
Dscho

Johan Henriksson

unread,
Aug 14, 2009, 6:33:25 PM8/14/09
to ima...@googlegroups.com
On Fri, Aug 14, 2009 at 10:47 AM, Stephan Saalfeld <saal...@mpi-cbg.de> wrote:



I am struggling with this myself for endrov and I don't believe in your design. summarizing the problems making it almost impossible to come up with a good design:

1. no generics over scalar types (but int.class actually works! a pile of hacks)
2. generics is done through pointers, there is no c++ style cut and paste templating, hence no inlining
3. no cross-class inlining (so I heard, please prove me wrong)
4. generics by erasure, type information is lost and java has to do extra type checking in runtime

1 makes it impossible to do e.g. myclass<Double> which would make most sense.
2 & 3 makes any iterator over single pixels dirt-slow. calling functions is not for free, especially not virtual ones. 4 may make it slower in addition.

I have sent a suggestion for java 7 to include c++ style generics but I don't expect much, and if apple yet again is going to be 2-3 years late in releasing it, I can't use it anyway (if my boss didn't like apple, I would maybe have dropped support for it by now; please stop using OSX everyone).

I have given up on hacking around these problems. instead I will attempt to write a templating mechanism for java. hopefully as a byte-code runtime modification. templating is trivial to code on source level *but* I don't want to add new special syntax; I want to be able to use a normal IDE with all the bells and whistles it comes with. this is why it hasn't yet been implemented, it's a tricky requirement to fulfill.

another note when designing a solution: consider the advanced algorithms first. I have found it too easy to find nice solutions that just cannot be generalized, and then you're back to square one.

/Johan


--
-----------------------------------------------------------
Johan Henriksson

Curtis Rueden

unread,
Aug 31, 2009, 1:48:29 PM8/31/09
to ima...@googlegroups.com
Hi everyone,


On Thu, Jul 30, 2009 at 1:50 PM, Curtis Rueden <ctrued...@gmail.com> wrote:
We will hear back about our GO grant proposal very soon (early August, I think). Once we know how it fared, I will reply back to the list. Regarding "concrete ideas," I spelled out some technical aims in the proposal, which I would be glad to reiterate here. Ultimately though, the only way to get completely precise will be to start actually trying the proposed changes on the codebase, and seeing what the consequences are.

Our grant application was well received with a good score, but not good enough to get funded. I have uploaded a brief summary of the technical aims of the grant to the group ("ImageJ Hardening aims.rtf"). I know that the Fiji has already tackled (or is working on) many of these, but nonetheless they are what we identified as the major goals to produce a "next generation" version of ImageJ while maintaining compatibility and the existing community.

These aims do not include much of an attempt to address the "image container" issues discussed recently in this thread. While I agree that it would be nice to eliminate the ugliness of case-by-case pixel type handling, as Johan points out it is quite challenging to do so efficiently in Java, especially while preserving backwards compatibility. ImageJ has many other outstanding shortcomings as well, particularly the model/view entanglement, that I feel should be addressed first.

Anyway, we will probably resubmit to NIH's regular "continued development and maintenance of software" call at a later date.

-Curtis

Bill Mohler

unread,
Aug 31, 2009, 1:52:48 PM8/31/09
to ima...@googlegroups.com
Sorry to hear the grant didn't get funded.  I know it would have been worth it if it had.

Bill
Reply all
Reply to author
Forward
0 new messages