http://imagej.273.s1.nabble.com/Some-thoughts-about-ImageJ-tp3693353p3693365.html
I suppose efficient DFT/FFT functionality could be added to the ImageJ "core" any time without disturbing existing code.
> -----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
> ______________________________________________________________________
>