Posted by
Frederic V. Hessman on
Mar 10, 2009; 5:17pm
URL: http://imagej.273.s1.nabble.com/Some-thoughts-about-ImageJ-tp3693353p3693360.html
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