Re: imageJ + distributed computing

Posted by dscho on Sep 30, 2010; 12:41am
URL: http://imagej.273.s1.nabble.com/imageJ-distributed-computing-tp3686733p3686739.html

Hi,

On Wed, 29 Sep 2010, Sean, Founder CloudSpree wrote:

> Is this something many imageJ users would be interested in?

I would be interested.

> I ask as I am contemplating developing a solution but have no desire to
> reinvent the wheel.
>
> Are many people waiting hours/days/weeks to batch process images?

The big problem is to formulate a simple yet powerful interface for this
which is feasible.

For example, you will never be able to parallelize in general a given
macro. But you could provide a way to do the Process>Batch>Macro... in a
truly parallel manner, say, on a cluster.

However. The big problem is that ImageJ was designed as a desktop
application, and therefore many plugins require a graphical desktop even
if they do not display anything. For example, if you instantiate any
java.awt.Dialog on Linux, you need a graphical desktop.

We tried to work around this issue in the 'headless' hack in Fiji
(basically providing fake Dialog and Menus classes), but fact is: many
plugins will fail to run with that hack, because they access more
functionality than we provide, e.g. registering callbacks such as
constraining the aspect ratio when downsampling. And our fake Dialog
class does not provide all required fake methods for that.

Oh, and by the way, if anybody wants to throw about with buzzwords such as
map/reduce, I would be interested in _concrete_ suggestions how that
should work, rather than just names of implementations of the paradigm. I
am interested in a concrete such suggestion, because the map/reduce
paradigm and ImageJ's plugin infrastructure appear to be completely
incompatible to me. But I have been wrong before. So: prove me wrong.
Concretely, not with PR speak.

Ciao,
Johannes