[ImageJ-devel] Auto-Documentation of Processing Chain: Extension of @Parameter Annotation

[Stefan Posch]

Hi,

On Wed, May 18, 2011 at 03:02:37PM +0100, Gabriel Landini wrote:
> This sounds quite interesting. Something that I wonder is how is the workflow 
> merged when let's say we operates images each with related or unrelated 
> histories.

This answer refers to Alida&Mitobo which we are developing
(where Alida is the basis for automatic documentation and mitobo our framework for
image analysis building on Alida and IJ).
Alidas processing histories nd IJs workflows are very likely
similar concepts.
As posted recently we experimentally integrated Alida into IJ2 (at our site).

> Let's suppose that one wishes to divide a current image -with all its history 
> of processes- by another image -with its history of processes too. The second 
> image might be derived from the first one too.
> 
> It might be that unless all this is started from scratch and recorded every 
> step, on has lots of unknowns in the workflow? Is the idea to do this by 
> default or only when required, like with the macro recorder?
> 
> And where are all these workflow histories stored? With the images themselves?
Starting with the last question:
In Mitobo, each image (as well as other data, like segmentation result, e.g. snakes)
written to disk is accomandied by an additional .ald history file containing the processing history.

If this image (or file containing snakes) is read lateron the .ald file containing the history is read also,
(in IJ you have to use the ReadImage Plugin which is part of Mitobo)
and internally linked into the implicit processing graph build on the fly when operators are invoked.

If the result of the second processing pipeline is written to disk, the first history is
included and also saved to disk.

Fig A.1 of the Alida-Manual
(http://www2.informatik.uni-halle.de/agprbio/alida/downloads/manual/AlidaManual.pdf)
shows an example where the image in file "nuc-corrected.pgm" was in a first session 
created applying a gamma correction on a image read from file.
The file "nuc-corrected.pgm" and the image in "pd.pgm" are read in a later session 
and the operator CellSegmentation is invoked,
which uses nested calls to further opertors (e.g. DectectNucleim ActiveContours).

The fact, that the history of nuc-corrected stems from a previous session is visualized
by the orange colour of the triangle.
The source image of the gamma correction is hidden in this view, as the ReadImage sending its output
to MTBGammaCorrection has been collapsed. In Fig A.2 on the second page, it is uncollapsed, 
and we see, it was read from fiel "nuc.pgm".

If this file would be identical to "pg.pgm", this would currently not be identified by Alida/Mitobo
as this would require to identify persistently stored (image) data. I do not think this is possible
for data on disk (easily) (unless we have unique IDs), of course would be feasable if we use a database.

In Alida all invocations of operators (roughly corresponding to plugins) are transparently recorded, unless
the _programmer_ who invokes the operator refrains from doing so.

Hope this helps .... and dont't hesitate to send further questions

Regards

Stefan
-- 
Prof. Dr.-Ing. Stefan Posch,
        Institut fuer Informatik, Martin-Luther-Universitaet Halle-Wittenberg
        Von-Seckendorff-Platz 1, 06099 Halle (Saale)
phone:  ++49 345 55-24728
fax:	++49 345 55-27039
e-mail: Stefan.Posch at informatik.uni-halle.de
www:    www.informatik.uni-halle.de/~posch/