Re: Some thoughts about ImageJ ...

Posted by Wayne Rasband on Mar 10, 2009; 12:16am
URL: http://imagej.273.s1.nabble.com/Some-thoughts-about-ImageJ-tp3693353p3693373.html

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>