Posted by
Burger Wilhelm on
Mar 09, 2009; 4:36pm
URL: http://imagej.273.s1.nabble.com/Some-thoughts-about-ImageJ-tp3693353.html
Dear ImageJ community,
I have been working with IJ for many years, mainly as a teaching aid and
a tool for implementing small imaging projects. Having used several
other environments before, I immediately loved IJ for its simplicity,
openness, portability, and the fact that it was pure Java - the premiere
programming language in many undergraduate curricula! Despite its
shortcomings, the phantastic effort by Wayne made me very confident that
IJ would constantly improve and develop in the right directions.
Eventually, this was also a key motive to select IJ as the programming
platform for our book (www.imagingbook.com), which hopefully didn't hurt
its popularity.
Unfortunately, at least from my point of view, IJ development has taken
a different and unexpected focus in the recent past. Understanding that
many users (and some developers) appreciate the ease of working with
macros or scripting languages, I always considered the use of a *single*
language with precise semantics as one exciting feature of IJ. This
contrasts many other Java-based environments that build on a C/C++ layer
for better performance, thereby compromising on simplicity and
portability. Personally I think that combining two (or more) programming
paradigms should be avoided unless they are radically different from
each other (e.g., LISP + C) and the combination provides a substantial
overall advantage. Most scripting languages, though, seem to be too
close to Java anyway (some are even named similarly), both in terms of
syntax and performance, and also lack the great benefits of compile-time
error checking provided in Java (and other modern languages). This is
one reason why I always preferred ImageJ over Matlab, for example.
Despite its obvious benefits, I am afraid I perceive the current
emphasis on scripting as a dilution of ImageJ's original spirit.
What I (as a developer) would have much liked to see (instead or in
addition) is a gradual improvement of ImageJ's core API to make it
semantically cleaner, more orthogonal, flexible, robust and
object-oriented, which is important if used as a didactic tool.
Unfortunately, although Wayne does a wonderful job in fixing all sorts
of immediate problems, any major changes to the API seem to be
completely impossible at this point without immediately breaking
existing code. I perceive this situation as frustrating because I feel
ImageJ is stuck and has no chance to evolve to the quality where it
could be. Efforts like Fiji to set up and maintain consistent
multi-functional packages, though extremely useful for many in the
community, seem to pursue completely different goals.
I guess what I am proposing is a complete rewrite of ImageJ from
scratch, following the same concept but giving up on any backward
compatibility. Ad hoc, key goals (among others) would include to ...
+ improve semantics and orthogonality of the API,
+ clearly separate data representation from viewing,
+ create core libraries that can be used in other environments with
minimal
interdependencies between classes,
+ maximize compile-time safety by avoiding typecasts and eliminating
run-time
type checking wherever possible,
+ make extensive use of modern Java features,
+ extend the plugin mechanism to operate on multiple images and other
data types,
+ improve performance to allow real-time applications (possibly using
native calls,
GPU-code etc.),
+ ...
Does this sound completely insane? Is it too late for this? Anyone
interested in sharing ideas or even in collaborating (eventually)?
Wow, this grew to a long message - cannot wait for your comments!
Sincerely,
Wilhelm
--
Dr. Wilhelm BURGER
| Upper Austria Univ. of Applied Sciences
| Digital Media Department
| A-4232 Hagenberg, Austria
| mailto:
[hidden email]
| www.imagingbook.com