[ImageJ-devel] [fiji-devel] Status reporting in ImgLib Algorithms

[Johannes Schindelin]

Hi Curtis,

On Mon, 5 Aug 2013, Curtis Rueden wrote:

> On Mon, Aug 5, 2013 at 11:01 AM, Tobias Pietzsch
> <pietzsch at mpi-cbg.de>wrote:
> 
> > I think the overhead will be quite high in some cases. For instance in
> > your forked ComputeMinMax algorithm you do some work on updating
> > status for every single pixel, which I think is definitely overdoing
> > it.
> 
> Yes, there is always a tradeoff, and a balance, for this problem. I
> agree that status-per-pixel is overkill.
> 
> What about polling? Another option might be for ImgLib2 algorithms to
> update some (standardized) internal state, but not inform anyone about
> such changes. Then downstream code could poll that state every X
> milliseconds.

I agree that there is a danger of overkill. Unfortunately, the same danger
applies to the core library trying to think for the consumers.

A concrete example how things can be decoupled can be found in ImageJ 1.x:
the algorithms typically update their prograss on a slice-by-slice basis,
or if the algorithm is known to be expensive, pixel line by pixel line. Of
course, for small images this still meant that the progress updates would
dominate the execution time (undesirable, of course).

ImageJ 1.x deals with it by having its own internal state in the progress
update that skips progress updates if they come in too fast.

Likewise, I would suggest that ImgLib2 does not try to think for the
status reporter. Instead, there should be a way to report the status. Full
stop. The status reporter consuming those calls would need to do something
IJ1-like if there is a performance problem.

Let's separate concerns properly,
Dscho