Some thoughts about ImageJ ...

[Burger Wilhelm]

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

[dscho]

Hi,

On Mon, 9 Mar 2009, Burger Wilhelm wrote:

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

You mix two substantially different things here.  The use of scripting
languages makes ImageJ no less portable, provided that the languages
themselves are implemented in Java.

So using Clojure, Jython, Javascript, JRuby or BeanShell does not affect
portability and ease of installation at all.

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

I have to disagree.  The lack of strict typing can be an advantage.  
Remember: the time it takes to perform a specific task is the time it
takes for you to write the code plus the time it takes to run the code.

So, if you have a cute idea that you want to test quickly, it is a good
thing if you can just jot down a simple Jython script (that would fail
utterly when fed the inappropriate data) without strict typing and
exception handling.  It makes the difference between 5 minutes and 1 hour.

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

Those are laudable goals, even if you do not restrict the use to a
didactic purpuse (which is rather limiting the focus).

> 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 agree that it can be hard to provide major changes to the API without
breaking existing code.

For the end user, though, the API is not important.  The existing code is.

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

One of the goals of Fiji is to provide an easy platform to develop for
ImageJ, but also ImageJ itself.

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

Heh.  I am aware of a project which tries to rewrite something like
ImageJ.  Unfortunately, even if they claim that the project is available
under the BSD license, in reality you will not get the source code.  So
they lied.

But it is a major task.  And you make all those plugins that are in
wide-spread use completely useless in the process.

> Is it too late for this?

It is never too late.  In Open Source, you are free to do what you want.

> Anyone interested in sharing ideas or even in collaborating
> (eventually)?

Yes.

But I propose a different strategy: Keep ImageJ as it is, but provide
adapters to a new, well planned API relying on Java5 features.  Write
adapters so that the API can be used seamlessly from within ImageJ.  Use
the collaborative framework provided by Fiji.  Gradually port plugins to
the new API.  Introduce shortcuts in ImageJ to make efficient use of the
new API.

This way, you can keep existing users as well as future developers happy.

Ciao,
Dscho

[Gluender-2]

Dear colleague Burger,

for me there is only one answer: Go ahead!

.. but please leave ImageJ as is.

ImageJ is used by thousands of scientists as a
valuable tool (and it was conceptualized as such)
and there exist enormous amounts of macros and
plug-ins that are used regularly over long
periods of times without the need of adaptation.
Most of us use ImageJ as a tool and besides many
other features we love the ease of rapid
prototyping by using the macro language.

From a programmers point of view things may look
different, but this is an old story going back to
the early days of computers when there were
people who wanted to use computers to solve
problems and those who wanted to refine
programming...

Just my 5 cents.

Best

Herbie Glünder

>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

--

                   Herbie

          ------------------------
          <http://www.gluender.de>

[Gerard van Schip]

Don't laugh...

Can anyone point me to a good website that shows all the things you can
do with ImageJ with examples?

I only downloaded ImageJ as it is the only software that runs on the Mac
and features the FFT plugin which I use to remove repeating patterns
from old photos but now I keep reading all your posts I get super
curious what else I can do with ImageJ.

Thanks.

Gerard

Gluender wrote:

> Dear colleague Burger,
>
> for me there is only one answer: Go ahead!
>
> .. but please leave ImageJ as is.
>
> ImageJ is used by thousands of scientists as a valuable tool (and it
> was conceptualized as such) and there exist enormous amounts of macros
> and plug-ins that are used regularly over long periods of times
> without the need of adaptation. Most of us use ImageJ as a tool and
> besides many other features we love the ease of rapid prototyping by
> using the macro language.
>
> From a programmers point of view things may look different, but this
> is an old story going back to the early days of computers when there
> were people who wanted to use computers to solve problems and those
> who wanted to refine programming...
>
> Just my 5 cents.
>
> Best
>
> Herbie Glünder
>
>> 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
>
>

[Joelle Abi Char]

regards,
this might be helpful
http://www.macbiophotonics.ca/imagej/

regards,
Joelle
 
Abi Char Joëlle, PhD
Laboratory of Experimental Cardiology
Herestraat 49, Campus Gasthuisberg
O&N1, Bus 704
B-3000 Leuven
Belgium
Tel:  [phone]
Fax: [phone]

 




________________________________
From: Gerard van Schip <>
To: [hidden email]
Sent: Monday, March 9, 2009 6:06:59 PM
Subject: Re: Some thoughts about ImageJ ...

Don't laugh...

Can anyone point me to a good website that shows all the things you can
do with ImageJ with examples?

I only downloaded ImageJ as it is the only software that runs on the Mac
and features the FFT plugin which I use to remove repeating patterns
from old photos but now I keep reading all your posts I get super
curious what else I can do with ImageJ.

Thanks.

Gerard

Gluender wrote:

> Dear colleague Burger,
>
> for me there is only one answer: Go ahead!
>
> .. but please leave ImageJ as is.
>
> ImageJ is used by thousands of scientists as a valuable tool (and it
> was conceptualized as such) and there exist enormous amounts of macros
> and plug-ins that are used regularly over long periods of times
> without the need of adaptation. Most of us use ImageJ as a tool and
> besides many other features we love the ease of rapid prototyping by
> using the macro language.
>
> From a programmers point of view things may look different, but this
> is an old story going back to the early days of computers when there
> were people who wanted to use computers to solve problems and those
> who wanted to refine programming...
>
> Just my 5 cents.
>
> Best
>
> Herbie Glünder
>
>> 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
>
>

[Albert Cardona]

Wilhem,


> Does this sound completely insane? Is it too late for this? Anyone
> interested in sharing ideas or even in collaborating (eventually)?


There is a growing group of people interested in rewriting at least parts
of
ImageJ. In very short, this is how I envision the process:


  1. Create the underlying data structures as classes, but based on
interfaces.
The goals are many. First, being able to run ImageJ with different GUI
toolkits
(java 3D comes to mind), or with none at all (headless, or as a library).
Second, to implement different data I/O routines and caching (like paged
memory
blocks based on cubes, or on slices--the current model--, or in combination
with a pyramid strategy. Third, to represent images as tensors; that is,
with
any number of dimensions (color channels, time, alpha, anything), all
seamlessly accessible. The current ImageJ datastructures would be a subset.


2. Provide interfaces for all the current set of ImageJ core classes, to
set
   a layer of compatibility with current plugins.


All that current plugins would need is a recompile. Some plugins would
break:
those relying on direct access to public fields, like ImagePlus.changes
flag.
But such breaking changes would not be too hard to fix; the key element
here
being to focus one's time and resources on plugins of interest.  Those
plugins
without source code available would limit themselves to run with current
ImageJ, which is just fine.

Some of the work above has started, so far uncoordinated.

A major concern is awareness: ImageJ is a lot more than just the ij.jar.
It's
the life work of Wayne, is the knitting of a very large and very diverse
interest group, and it's the inertia of the current user model and the
constrains of the data structures. Changing the latter may break the link
with
the rest. Are you ready to commit to a project that would deliver it all,
beyond the academic circles? Otherwise it would all be just an exercise,
like
yet one more unpolished and unmaintained matlab script released with a
computer
science paper, no matter how good or how promising.

Albert
--
Albert Cardona
http://albert.rierol.net

[Robert Dougherty]

Dscho,

>
>
> So using Clojure, Jython, Javascript, JRuby or BeanShell does not  
> affect
> portability and ease of installation at all.
>
>>

One of my favorite features of ImageJ is that it provides it own  
simple development environment: Compile And Run....  I don't like  
spending time setting up environments and learning languages.  This  
overhead is a distraction from working on science and engineering  
projects.  On the other hand, keeping up with computer science  
developments is also important.  I don't think I would be very  
effective if I still programmed in FORTRAN 77.  In many ways, Java's  
structure lends itself to rapid, correct development and taking  
advantage of a range of APIs.  (In other ways, of course, it is  
frustrating.)  I could be wrong, but it seems to me that ImageJ is a  
good as Java APIs get.  It is certainly more solid than Java Sound  
or, sigh, Quicktime for Java.  So how to identify the real way  
forward?   Ask Wayne? We are are all standing on his shoulders.

Bob


Robert Dougherty, Ph.D.
President, OptiNav, Inc.
4176 148th Ave. NE
Redmond, WA 98052
Tel. [phone]
FAX [phone]
www.optinav.com
[hidden email]

[dscho]

Hi Bob,

On Mon, 9 Mar 2009, Robert Dougherty wrote:

> >So using Clojure, Jython, Javascript, JRuby or BeanShell does not
> >affect portability and ease of installation at all.
>
> One of my favorite features of ImageJ is that it provides it own simple
> development environment: Compile And Run....

Yes, but that means that you have to take care of declaring the types,
casting and converting the class instances properly, and you have to catch
exceptions.

If the real job is to test a new idea, I tend to script the thing in
Jython, and most of the time there is a fundamental problem with the idea.

I can then spend more time to try to fix the idea, or just forget about
that approach.

In both cases, I saved time.

> I don't like spending time setting up environments and learning
> languages.

You definitely do not need to!  But I like the freedom for people who
already know certain languages.

> I could be wrong, but it seems to me that ImageJ is a good as Java APIs
> get.  It is certainly more solid than Java Sound or, sigh, Quicktime for
> Java.

I certainly is!

> the real way forward?  Ask Wayne?

As far as ImageJ is concerned: Wayne decides.  That is just a fact.

> We are are all standing on his shoulders.

Oh, definitely.  I sometimes look back to the olden days of fighting
Amira's awkward-or-not-existing documentation and the long development
cycles, and I am so thankful that I do not have to suffer that anymore.

Wayne, if I haven't thanked you today yet: Thank you!

Ciao,
Dscho

[Wayne Rasband]

On Mar 9, 2009, at 1:01 PM, Gluender wrote:

> Dear colleague Burger,
>
> for me there is only one answer: Go ahead!
>
> .. but please leave ImageJ as is.
>
> ImageJ is used by thousands of scientists as a valuable tool (and  
> it was conceptualized as such) and there exist enormous amounts of  
> macros and plug-ins that are used regularly over long periods of  
> times without the need of adaptation. Most of us use ImageJ as a  
> tool and besides many other features we love the ease of rapid  
> prototyping by using the macro language.
>
> From a programmers point of view things may look different, but  
> this is an old story going back to the early days of computers when  
> there were people who wanted to use computers to solve problems and  
> those who wanted to refine programming...
>
> Just my 5 cents.
>
> Best
>
> Herbie Glünder

I agree with Herbie.

-wayne

>
>> 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
>
>
> --
>
>                   Herbie
>
>          ------------------------
>          <http://www.gluender.de>

[Joachim Wesner]

ImageJ Interest Group <[hidden email]> schrieb am 09.03.2009 20:33:10:

> Dscho,
>
> >
> >
> > So using Clojure, Jython, Javascript, JRuby or BeanShell does not
> > affect
> > portability and ease of installation at all.
> >
> >>
>
> One of my favorite features of ImageJ is that it provides it own
> simple development environment: Compile And Run....  I don't like
> spending time setting up environments and learning languages.  This
> overhead is a distraction from working on science and engineering
> projects.  On the other hand, keeping up with computer science
> developments is also important.  I don't think I would be very
> effective if I still programmed in FORTRAN 77.  In many ways, Java's
> structure lends itself to rapid, correct development and taking
> advantage of a range of APIs.  (In other ways, of course, it is
> frustrating.)  I could be wrong, but it seems to me that ImageJ is a
> good as Java APIs get.  It is certainly more solid than Java Sound
> or, sigh, Quicktime for Java.  So how to identify the real way
> forward?   Ask Wayne? We are are all standing on his shoulders.
>

Haha, nice to hear that, even after several attempts with Eclipse etc. I
still
prefer the built-in editor even for intermediately complex plugins as 2D
Phase unwrapping,
fringe processing, interferogram data viewing using a JTable and
reconstruction
(including the ability to later change tilt, defocus and introduce other
artificial aberrations, just
like you would be sitting at the true interferometer), show the respective
PSF etc.etc.


Maybe that´s because I´m one of those old fashioned guys that grew up with
Fortran IV
and V (Univac 1108 Fortran!!) and initially only a deck of cards.....

By the way, there is an old little change request for the internal editor
of ImageJ: Could the editor
remember the latest "Case sensitivity" setting between restart? It always
comes up again with "Case Sensitive"

Thanx

Cheers


Joachim



______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________

[Grant Harris]

As some of you know, I have been experimenting with how to refactor ImageJ
to decoupling the essential image processing functionality from specific UI
components to facilitate such things as incorporating ImageJ into an MDI or
Docking environment.  While I had originally believed that a refactoring
could be done that would maintain complete source compatability (only
requiring that plugins be recompiled),  I now think that some incompatible
changes are necessary if ImageJ is to jump to the next level – perhaps we
could call this process "Evolving ImageJ to an Extensible Imaging Framework."
 
This discussion confirms that there are a significant number of like-minded
ImageJ developers who might be willing to contribute to such an effort.  I
agree with Albert that there needs to be a commitment by a core group of
people to follow such a project through to completion.  If is time to
bite-the-bullet and make some incompatible changes, I think it is important
to develop a transition strategy that doesn't create chaos in the user
community.   And I would also encourage us to consider collaborating with
some of the other significant players in the ImageJ community, specifically
OME/OMERO (metadata and image management),  LOCI at Univ.
Wisconsin(Bio-Formats & VisBio), and microManager at UCSF (acquisition control).

To facilitate the initial discussion, I set up Google Group called "ImageJX"
 (http://groups.google.com/group/imagejx) and a Google Code project called
"ijx" (http://code.google.com/p/ijx/).  Feel free to join the group, and
I'll add anyone who is interested to the members list on the project.  If
anyone feels that Fiji or some other site is a better tool for this, let me
know.  Or we can continue the discussion here on the mailing list.

-- Grant B. Harris
-----------------------------------------------------
Instrumentation Engineer, Cellular Dynamics Program
Marine Biological Laboratory, Woods Hole, Mass. 02543  
508-289-7374  cell:508-631-2141  [hidden email]

[Burger Wilhelm]

Thanks to all who took the interest and time to respond to my initial
posting - I agree with many (not all) of the arguments raised and the
picture I got is quite clear. Thanks also to Grant for setting up this
new platform and his suggestion to continue the discussion outside the
mailing list.

Wilhelm

> -----Original Message-----
> From: ImageJ Interest Group [mailto:[hidden email]] On
> Behalf Of Grant Harris
> Sent: Tuesday, March 10, 2009 2:21 PM
> To: [hidden email]
> Subject: Re: Some thoughts about ImageJ ...
>
> As some of you know, I have been experimenting with how to
> refactor ImageJ
> to decoupling the essential image processing functionality
> from specific UI
> components to facilitate such things as incorporating ImageJ
> into an MDI or
> Docking environment.  While I had originally believed that a
> refactoring
> could be done that would maintain complete source compatability (only
> requiring that plugins be recompiled),  I now think that some
> incompatible
> changes are necessary if ImageJ is to jump to the next level
> - perhaps we
> could call this process "Evolving ImageJ to an Extensible
> Imaging Framework."
>  
> This discussion confirms that there are a significant number
> of like-minded
> ImageJ developers who might be willing to contribute to such
> an effort.  I
> agree with Albert that there needs to be a commitment by a
> core group of
> people to follow such a project through to completion.  If is time to
> bite-the-bullet and make some incompatible changes, I think
> it is important
> to develop a transition strategy that doesn't create chaos in the user
> community.   And I would also encourage us to consider
> collaborating with
> some of the other significant players in the ImageJ
> community, specifically
> OME/OMERO (metadata and image management),  LOCI at Univ.
> Wisconsin(Bio-Formats & VisBio), and microManager at UCSF
> (acquisition control).
>
> To facilitate the initial discussion, I set up Google Group
> called "ImageJX"
>  (http://groups.google.com/group/imagejx) and a Google Code
> project called
> "ijx" (http://code.google.com/p/ijx/).  Feel free to join the
> group, and
> I'll add anyone who is interested to the members list on the
> project.  If
> anyone feels that Fiji or some other site is a better tool
> for this, let me
> know.  Or we can continue the discussion here on the mailing list.
>
> -- Grant B. Harris
> -----------------------------------------------------
> Instrumentation Engineer, Cellular Dynamics Program
> Marine Biological Laboratory, Woods Hole, Mass. 02543  
> 508-289-7374  cell:508-631-2141  [hidden email]
>

[Joachim Wesner]

One thing that should/could be adressed when "refactoring" ImageJ
would/could/SHOULD be the way the
FFT or FHT routines are integrated into the "kernel". In the current way,
they are difficult to use from another
plugin, if not on the "run()" level,which is IMHO effectively "macro
programming", causing many plugins to
come up with their own FFT package.

Also, on todays modern systems that have fast FPU integrated, FHT has NO
real speed benefit over similar "true" FFT
or better an optimized "real-to-complex" FFT routines and this would avoid
the need for the clumsy FFT<->FHT wrapper
routines I once added.

For a "proof" on this, see the Wikipedia article on FFT:

"It was once believed that real-input DFTs could be more efficiently
computed by means of the discrete Hartley transform (DHT),
but it was subsequently argued that a specialized real-input DFT algorithm
(FFT) can typically be found that requires fewer
operations than the corresponding DHT algorithm (FHT) for the same number
of inputs." (I think this is based on a long paper
by one of the main developers of the FFTW package that I remember, but I
don´t have the link to in the moment)

In any case, the speed difference will be marginal!

Joachim


ImageJ Interest Group <[hidden email]> schrieb am 09.03.2009 18:29:53:

> Wilhem,
>
>
> > Does this sound completely insane? Is it too late for this? Anyone
> > interested in sharing ideas or even in collaborating (eventually)?
>
>
> There is a growing group of people interested in rewriting at least parts
> of
> ImageJ. In very short, this is how I envision the process:
>
>
>   1. Create the underlying data structures as classes, but based on
> interfaces.
> The goals are many. First, being able to run ImageJ with different GUI
> toolkits
> (java 3D comes to mind), or with none at all (headless, or as a library).
> Second, to implement different data I/O routines and caching (like paged
> memory
> blocks based on cubes, or on slices--the current model--, or in

combination
> with a pyramid strategy. Third, to represent images as tensors; that is,
> with
> any number of dimensions (color channels, time, alpha, anything), all
> seamlessly accessible. The current ImageJ datastructures would be a
subset.

>
>
> 2. Provide interfaces for all the current set of ImageJ core classes, to
> set
>    a layer of compatibility with current plugins.
>
>
> All that current plugins would need is a recompile. Some plugins would
> break:
> those relying on direct access to public fields, like ImagePlus.changes
> flag.
> But such breaking changes would not be too hard to fix; the key element
> here
> being to focus one's time and resources on plugins of interest.  Those
> plugins
> without source code available would limit themselves to run with current
> ImageJ, which is just fine.
>
> Some of the work above has started, so far uncoordinated.
>
> A major concern is awareness: ImageJ is a lot more than just the ij.jar.
> It's
> the life work of Wayne, is the knitting of a very large and very diverse
> interest group, and it's the inertia of the current user model and the
> constrains of the data structures. Changing the latter may break the link
> with
> the rest. Are you ready to commit to a project that would deliver it all,
> beyond the academic circles? Otherwise it would all be just an exercise,
> like
> yet one more unpolished and unmaintained matlab script released with a
> computer
> science paper, no matter how good or how promising.
>
> Albert
> --
> Albert Cardona
> http://albert.rierol.net

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________

[dscho]

Hi,

On Tue, 10 Mar 2009, Joachim Wesner wrote:

> One thing that should/could be adressed when "refactoring" ImageJ
> would/could/SHOULD be the way the FFT or FHT routines are integrated
> into the "kernel".

This is getting too detailed for me.  We are losing focus.

The real issue is, after all: due to historical reasons, ImageJ uses
neither Java5 niceties, nor does it have a completely orthogonal API
(meaning that GUI, data structures and algorithms are not separated from
each other).

The question is: how can we keep the convenience for existing users, as
well as get the changes in that are needed to move ImageJ forward from the
technical side?

Oh, and FWIW I think it would be wrong to move the discussion away from
the ImageJ list, unless you absolutely want to lose contact with the
users...

Ciao,
Dscho

[Burger Wilhelm]

I suppose efficient DFT/FFT functionality could be added to the ImageJ "core" any time without disturbing existing code.

Wilhelm

> -----Original Message-----
> From: ImageJ Interest Group [mailto:[hidden email]] On
> Behalf Of Joachim Wesner
> Sent: Tuesday, March 10, 2009 3:26 PM
> To: [hidden email]
> Subject: Antwort: Re: Some thoughts about ImageJ ...
>
> One thing that should/could be adressed when "refactoring" ImageJ
> would/could/SHOULD be the way the
> FFT or FHT routines are integrated into the "kernel". In the
> current way,
> they are difficult to use from another
> plugin, if not on the "run()" level,which is IMHO effectively "macro
> programming", causing many plugins to
> come up with their own FFT package.
>
> Also, on todays modern systems that have fast FPU integrated,
> FHT has NO
> real speed benefit over similar "true" FFT
> or better an optimized "real-to-complex" FFT routines and
> this would avoid
> the need for the clumsy FFT<->FHT wrapper
> routines I once added.
>
> For a "proof" on this, see the Wikipedia article on FFT:
>
> "It was once believed that real-input DFTs could be more efficiently
> computed by means of the discrete Hartley transform (DHT),
> but it was subsequently argued that a specialized real-input
> DFT algorithm
> (FFT) can typically be found that requires fewer
> operations than the corresponding DHT algorithm (FHT) for the
> same number
> of inputs." (I think this is based on a long paper
> by one of the main developers of the FFTW package that I
> remember, but I
> don´t have the link to in the moment)
>
> In any case, the speed difference will be marginal!
>
> Joachim
>
>
> ImageJ Interest Group <[hidden email]> schrieb am
> 09.03.2009 18:29:53:
>
> > Wilhem,
> >
> >
> > > Does this sound completely insane? Is it too late for this? Anyone
> > > interested in sharing ideas or even in collaborating (eventually)?
> >
> >
> > There is a growing group of people interested in rewriting
> at least parts
> > of
> > ImageJ. In very short, this is how I envision the process:
> >
> >
> >   1. Create the underlying data structures as classes, but based on
> > interfaces.
> > The goals are many. First, being able to run ImageJ with
> different GUI
> > toolkits
> > (java 3D comes to mind), or with none at all (headless, or
> as a library).
> > Second, to implement different data I/O routines and
> caching (like paged
> > memory
> > blocks based on cubes, or on slices--the current model--, or in
> combination
> > with a pyramid strategy. Third, to represent images as
> tensors; that is,
> > with
> > any number of dimensions (color channels, time, alpha,
> anything), all
> > seamlessly accessible. The current ImageJ datastructures would be a
> subset.
> >
> >
> > 2. Provide interfaces for all the current set of ImageJ
> core classes, to
> > set
> >    a layer of compatibility with current plugins.
> >
> >
> > All that current plugins would need is a recompile. Some
> plugins would
> > break:
> > those relying on direct access to public fields, like
> ImagePlus.changes
> > flag.
> > But such breaking changes would not be too hard to fix; the
> key element
> > here
> > being to focus one's time and resources on plugins of
> interest.  Those
> > plugins
> > without source code available would limit themselves to run
> with current
> > ImageJ, which is just fine.
> >
> > Some of the work above has started, so far uncoordinated.
> >
> > A major concern is awareness: ImageJ is a lot more than
> just the ij.jar.
> > It's
> > the life work of Wayne, is the knitting of a very large and
> very diverse
> > interest group, and it's the inertia of the current user
> model and the
> > constrains of the data structures. Changing the latter may
> break the link
> > with
> > the rest. Are you ready to commit to a project that would
> deliver it all,
> > beyond the academic circles? Otherwise it would all be just
> an exercise,
> > like
> > yet one more unpolished and unmaintained matlab script
> released with a
> > computer
> > science paper, no matter how good or how promising.
> >
> > Albert
> > --
> > Albert Cardona
> > http://albert.rierol.net
>
>
> ______________________________________________________________________
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email 
> ______________________________________________________________________
>

[Joris FA Meys]

Hi all,

I'm fairly new to programming in Java and in the world of ImageJ, so please
keep that in mind while reading my comments.

On Tue, Mar 10, 2009 at 3:35 PM, Johannes Schindelin <
[hidden email]> wrote:

> Hi,
>
> On Tue, 10 Mar 2009, Joachim Wesner wrote:
>
> > One thing that should/could be adressed when "refactoring" ImageJ
> > would/could/SHOULD be the way the FFT or FHT routines are integrated
> > into the "kernel".
>
> This is getting too detailed for me.  We are losing focus.

I agree on that one. As I understood, the point was to restructure ImageJ to
the latest insights and possibilities in programming in general, and Java
programming specifically. Which is an effort I personally encourage. It
would also enhance the applicability of ij classes and methods in other
applications. It is definitely possible now, and the documentation on the
use is very good as far as I'm concerned, but standardization would always
be nice.

>
>
> The real issue is, after all: due to historical reasons, ImageJ uses
> neither Java5 niceties, nor does it have a completely orthogonal API
> (meaning that GUI, data structures and algorithms are not separated from
> each other).

I would like to remark that quite some plugins drive on Java5 niceties like
object arrays and stuff. But then again, quite some of these more advanced
data structures slow down the calculations quite a bit. I have more
experience with this in Perl (e.g. nested hashes are a killer for your
runtime) , but in Java, it's as important, if not more as far as I know.

>
>
> The question is: how can we keep the convenience for existing users, as
> well as get the changes in that are needed to move ImageJ forward from the
> technical side?

This might be a pragmatic point of view, but it's impossible to do these
changes without breaking any code. Heck, my little plugin behaved already
drastically different depending on which version of the ij.jar I use in
Eclipse. But nothing keeps people from using a working version of the old
ImageJ to run the old plugins.

Popular plugins will only have to be updated where they use the classes from
the ij.jar. If they're built in a convenient way, much of the original code
will work anyway. If the rewriting of ImageJ does not alter the Plugin,
PluginFilter and PluginFrame interface, there's a good chance that quite
some plugins will still work.

>
>
> Oh, and FWIW I think it would be wrong to move the discussion away from
> the ImageJ list, unless you absolutely want to lose contact with the
> users...

That's a good point. But for carrying out the project, the users wouldn't
mind missing all the technical details. So those groups can definitely be
very useful.

Well, I'm not a great programmer, but I do know my way around Java by now
and I would be happy to contribute to this great idea.

And in the meantime, I would like to thank Wayne again for all the
marvellous work he did already, and the enormous help he is for the user
community. ImageJ as it is now, is an enormously great achievement.

Kind regards
Joris

[ctrueden]

Hi everyone,

Firstly I would like to respond to Herbie Glünder's comments about
maintaining compatibility versus elegant software design.

Herbie Glünder wrote:

> ImageJ is used by thousands of scientists as a valuable tool (and it was
> conceptualized as such) and there exist enormous amounts of macros and
> plug-ins that are used regularly over long periods of times without the need
> of adaptation. Most of us use ImageJ as a tool and besides many other
> features we love the ease of rapid prototyping by using the macro language.
>

I absolutely agree, for multiple reasons. From a purely pragmatic
standpoint, to be successful, a redesigned ImageJ would almost certainly
need to maintain compatibility with the vast body of existing work.

From a programmers point of view things may look different, but this is an
> old story going back to the early days of computers when there were people
> who wanted to use computers to solve problems and those who wanted to refine
> programming...
>

The dichotomy is not absolute. In many cases, with care it is possible to
have both. Moreover, I argue that to maximize ImageJ's effectiveness at
"solving problems," we must worry about "refining programming." Many of
those involved in this thread are not merely OCD design-obsessed programmers
-- our drive to retool the codebase specifically stems from encountering its
limitations in solving our problems. A complete refactoring, done
thoughtfully, would greatly benefit not just programmers, but users as well.

Johannes Schindelin wrote:

> The real issue is, after all: due to historical reasons, ImageJ uses
> neither Java5 niceties, nor does it have a completely orthogonal API
> (meaning that GUI, data structures and algorithms are not separated from
> each other).
>

I agree that adapting ImageJ into an MVC design would solve a lot of
problems, allowing it to be far more flexible as a toolkit beyond just the
ImageJ core application.

The question is: how can we keep the convenience for existing users, as
> well as get the changes in that are needed to move ImageJ forward from the
> technical side?
>

First idea that comes to mind:

A) Redesign the architecture from the ground up, according to MVC and other
best practices. Create a new tree of packages rooted at "ij2" to house it.

B) Begin migrating code from the old ij package into the new ij2 package.
The ij package API would remain identical, but the "guts" would be shifting
into ij2 over time. The code driving the stable ij API would become simpler
as more and more of it becomes delegation to logic in ij2. This process
gives us the flexibility to develop ImageJ v2.x independently of ImageJ
v1.x.

C) Plugins and macros needing new functionality can be coded against the ij2
API, while old plugins that use ij will continue to work. Over time we can
add deprecation warnings to everything in ij.*, to encourage developers to
migrate to ij2 when possible.

Of course, there are many challenges with this approach, but it seems like a
good way to get the best of both worlds.

Grant, it sounds like you have done some substantial work toward step A
above. How far did you get? Who else is interested in retooling the API?

-Curtis

On Tue, Mar 10, 2009 at 9:35 AM, Johannes Schindelin <
[hidden email]> wrote:

> Hi,
>
> On Tue, 10 Mar 2009, Joachim Wesner wrote:
>
> > One thing that should/could be adressed when "refactoring" ImageJ
> > would/could/SHOULD be the way the FFT or FHT routines are integrated
> > into the "kernel".
>
> This is getting too detailed for me.  We are losing focus.
>
> The real issue is, after all: due to historical reasons, ImageJ uses
> neither Java5 niceties, nor does it have a completely orthogonal API
> (meaning that GUI, data structures and algorithms are not separated from
> each other).
>
> The question is: how can we keep the convenience for existing users, as
> well as get the changes in that are needed to move ImageJ forward from the
> technical side?
>
> Oh, and FWIW I think it would be wrong to move the discussion away from
> the ImageJ list, unless you absolutely want to lose contact with the
> users...
>
> Ciao,
> Dscho
>

[Frederic V. Hessman]

I see the only major problem with the current ImageJ class structure  
as not using a unified generic data model ("tensor") - something which  
is really frustrating when using ImageJ for astronomy, where the FITS  
support for arbitrary data spaces is fantastic - and the major GUI  
problem not supporting a full dynamic graphical representation of the  
data (plotted graphs are also "images").   The former could be  
implemented without the users knowing it, since the underlying data  
model could look like "images" and "stacks" and "hyperstacks".   The  
latter would be an add-on anyway.

This question is too complicated to leave on the standard list (which  
is already full enough) but also too important to leave to a few  
cogniscenti.  May I suggest that there be a off-line discussion and  
then a "public" report after there are some more concrete ideas of  
what we could do (and what Wayne would accept).

Rick

On 10 Mar 2009, at 3:35 pm, Johannes Schindelin wrote:

> Hi,
>
> On Tue, 10 Mar 2009, Joachim Wesner wrote:
>
>> One thing that should/could be adressed when "refactoring" ImageJ
>> would/could/SHOULD be the way the FFT or FHT routines are integrated
>> into the "kernel".
>
> This is getting too detailed for me.  We are losing focus.
>
> The real issue is, after all: due to historical reasons, ImageJ uses
> neither Java5 niceties, nor does it have a completely orthogonal API
> (meaning that GUI, data structures and algorithms are not separated  
> from
> each other).
>
> The question is: how can we keep the convenience for existing users,  
> as
> well as get the changes in that are needed to move ImageJ forward  
> from the
> technical side?
>
> Oh, and FWIW I think it would be wrong to move the discussion away  
> from
> the ImageJ list, unless you absolutely want to lose contact with the
> users...
>
> Ciao,
> Dscho

[Leonard Sitongia]

Frederic V. Hessman wrote:
> This question is too complicated to leave on the standard list (which
> is already full enough) but also too important to leave to a few
> cogniscenti.  May I suggest that there be a off-line discussion and
> then a "public" report after there are some more concrete ideas of
> what we could do (and what Wayne would accept).
I agree with this.  I worry that technical discussion is going to
overload people who are not interested and might cause them to quit this
list.

Before suggesting Grant's Google Group, is there already a list for
technical discussions?  If there isn't, then I think it would be great
if those interested in the technical stuff would join ImageJX and get
this discussion going there.  http://groups.google.com/group/imagejx

--
==Leonard E. Sitongia
   High Altitude Observatory
   National Center for Atmospheric Research
   P.O. Box 3000 Boulder CO 80307  USA
   [hidden email]  voice: [phone]  fax: [phone]

[Burger Wilhelm]

To be clear (before switching to the other list), the issue goes far
beyond the goal of using recent Java features. While these make some
things easier, safer and more elegant, the real task is to build on
proven general architectural models that existed long before Java 5.
This is not just for fun or because computing people want to
re-implement tools all the time using the current language of fashion -
in the contrary. I am very pragmatic about this (no mad computing freak)
and I would not have raised the issue if I did not experience that the
current deficits really are a limiting factor to ImageJ's future
development. I also have seen a lot of inefficient and fragile code in
contributed plugins and I believe this is partly due to the current API.

Also, I definitely have no objection against scripting languages (being
an ex-LISP person myself) - they are great for quick prototyping but
they do not lend themselves to building large, complex systems that are
modular and safe. I would even argue that the multitude of available
scripting options - though very convenient for the individual scipter -
is not supportive of code sharing in general.

Off now to the other list...

Wilhelm

> -----Original Message-----
> From: ImageJ Interest Group [mailto:[hidden email]] On
> Behalf Of joris meys
> Sent: Tuesday, March 10, 2009 5:40 PM
> To: [hidden email]
> Subject: Re: Antwort: Re: Some thoughts about ImageJ ...
>
> Hi all,
>
> I'm fairly new to programming in Java and in the world of
> ImageJ, so please
> keep that in mind while reading my comments.
>
> On Tue, Mar 10, 2009 at 3:35 PM, Johannes Schindelin <
> [hidden email]> wrote:
>
> > Hi,
> >
> > On Tue, 10 Mar 2009, Joachim Wesner wrote:
> >
> > > One thing that should/could be adressed when "refactoring" ImageJ
> > > would/could/SHOULD be the way the FFT or FHT routines are
> integrated
> > > into the "kernel".
> >
> > This is getting too detailed for me.  We are losing focus.
>
> I agree on that one. As I understood, the point was to
> restructure ImageJ to
> the latest insights and possibilities in programming in
> general, and Java
> programming specifically. Which is an effort I personally
> encourage. It
> would also enhance the applicability of ij classes and
> methods in other
> applications. It is definitely possible now, and the
> documentation on the
> use is very good as far as I'm concerned, but standardization
> would always
> be nice.
>
> >
> >
> > The real issue is, after all: due to historical reasons, ImageJ uses
> > neither Java5 niceties, nor does it have a completely orthogonal API
> > (meaning that GUI, data structures and algorithms are not
> separated from
> > each other).
>
> I would like to remark that quite some plugins drive on Java5
> niceties like
> object arrays and stuff. But then again, quite some of these
> more advanced
> data structures slow down the calculations quite a bit. I have more
> experience with this in Perl (e.g. nested hashes are a killer for your
> runtime) , but in Java, it's as important, if not more as far
> as I know.
>
> >
> >
> > The question is: how can we keep the convenience for
> existing users, as
> > well as get the changes in that are needed to move ImageJ
> forward from the
> > technical side?
>
> This might be a pragmatic point of view, but it's impossible
> to do these
> changes without breaking any code. Heck, my little plugin
> behaved already
> drastically different depending on which version of the
> ij.jar I use in
> Eclipse. But nothing keeps people from using a working
> version of the old
> ImageJ to run the old plugins.
>
> Popular plugins will only have to be updated where they use
> the classes from
> the ij.jar. If they're built in a convenient way, much of the
> original code
> will work anyway. If the rewriting of ImageJ does not alter
> the Plugin,
> PluginFilter and PluginFrame interface, there's a good chance
> that quite
> some plugins will still work.
>
> >
> >
> > Oh, and FWIW I think it would be wrong to move the
> discussion away from
> > the ImageJ list, unless you absolutely want to lose contact with the
> > users...
>
> That's a good point. But for carrying out the project, the
> users wouldn't
> mind missing all the technical details. So those groups can
> definitely be
> very useful.
>
> Well, I'm not a great programmer, but I do know my way around
> Java by now
> and I would be happy to contribute to this great idea.
>
> And in the meantime, I would like to thank Wayne again for all the
> marvellous work he did already, and the enormous help he is
> for the user
> community. ImageJ as it is now, is an enormously great achievement.
>
> Kind regards
> Joris
>