Posted by
Joachim Wesner on
Mar 10, 2009; 2:26pm
URL: http://imagej.273.s1.nabble.com/Some-thoughts-about-ImageJ-tp3693353p3693356.html
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
______________________________________________________________________