Save to a project

Hi all,



ImageJ has been my favorite processing program for a while. One thing I
would like to suggest is: should ImageJ add a function to save all windows
into one project? That may include all images (images, FFT, histogram and
whatever), each window position, loaded macro if any, ROI manager if any,
plus some comment or note for the project. I always feel necessary when I
have to deal with and compare several images. Does this make sense to anyone
else?



Thanks.



ZLi

[dscho]

Hi,

On Mon, 8 Jan 2007, ZQ wrote:

> ImageJ has been my favorite processing program for a while. One thing I
> would like to suggest is: should ImageJ add a function to save all
> windows into one project? That may include all images (images, FFT,
> histogram and whatever), each window position, loaded macro if any, ROI
> manager if any, plus some comment or note for the project. I always feel
> necessary when I have to deal with and compare several images. Does this
> make sense to anyone else?

Interesting idea. Reminds me of the "Save Network" function of Amira.

Ciao,
Dscho

[Gabriel Landini]

On Thursday 11 January 2007 08:54, Johannes Schindelin wrote:
> On Mon, 8 Jan 2007, ZQ wrote:
> > should ImageJ add a function to save all
> > windows into one project? That may include all images (images, FFT,
> > histogram and whatever)

> Interesting idea. Reminds me of the "Save Network" function of Amira.

Yes, it would be useful, but thinking about it, I am not sure if this could
actually work.
Surely one can write a macro to save to a project directory the Options, all
images that are are open, all text windows open, ROIs and any data in the
Results table (if any).

Then to open the project, one can load everything back (even one can load the
results back with the Results Table importer), but would this put IJ in
exactly the same state as when saved?
(for instance, saving a histogram window as an image does not save the data in
it, and I guess it is the same with the FFT images?, what about spatial and
greyscale calibration of each image, applied LUTs, stretched LUT but not
applied, ROIs in the manager, etc).
What about plugins that run in a different thread (like the threshold
adjuster)? Those would not retain the values set at the time of saving the
project. Think that some of those plugins take the current image as a
parameter. Wouldn't it be difficult to know what open plugin is acting on
which image?

Cheers

Gabriel

[ctrueden]

Hi,

I agree with Gabriel that completely saving everything, especially
image processing results that are not already directly saved to disk,
could be quite difficult -- or at the very least take up a lot of
space on disk.

One standard "Java way" of doing it would be to serialize everything
and write to a file. Serialization can be tricky but is often
surprisingly straightforward. Still, this would be a significant
effort to add to the ImageJ codebase.

Another option might be to harness the macro language. We are actually
looking into doing something like this for our 4D Data Browser plugin,
since it supports virtual stacks (partially cached datasets from
disk). The problem is that if you only have 20 image planes in RAM out
of 4000 planes, and the user chooses an image processing function from
the ImageJ menu such as Process>Smooth, it only applies to the image
planes currently linked into the image window (a single plane, in the
case of the 4D Data Browser). What would be very slick is for the
Browser to somehow notice that some command has been executed, similar
to the Macro Recorder picking it up, save that command to a
"preprocessing macro," and apply it to every image plane currently in
the cache. Then whenever the cache changes, apply the same
preprocessing sequence to the new items being cached. To the user,
this would appear as though he were browsing data already processed
with his earlier commands, though there would be some delay if the
command sequence was computationally expensive.

Similarly, to save an entire ImageJ session, just record every command
executed to a "restoration macro" that is written to the ImageJ
session file. The downsides are that restoration would take more time
in the case of computationally expensive commands, and use of any
plugin or command that is not fully scriptable would break the
feature.

-Curtis

On 1/11/07, Gabriel Landini <[hidden email]> wrote:

> On Thursday 11 January 2007 08:54, Johannes Schindelin wrote:
> > On Mon, 8 Jan 2007, ZQ wrote:
> > > should ImageJ add a function to save all
> > > windows into one project? That may include all images (images, FFT,
> > > histogram and whatever)
>
> > Interesting idea. Reminds me of the "Save Network" function of Amira.
>
> Yes, it would be useful, but thinking about it, I am not sure if this could
> actually work.
> Surely one can write a macro to save to a project directory the Options, all
> images that are are open, all text windows open, ROIs and any data in the
> Results table (if any).
>
> Then to open the project, one can load everything back (even one can load the
> results back with the Results Table importer), but would this put IJ in
> exactly the same state as when saved?
> (for instance, saving a histogram window as an image does not save the data in
> it, and I guess it is the same with the FFT images?, what about spatial and
> greyscale calibration of each image, applied LUTs, stretched LUT but not
> applied, ROIs in the manager, etc).
> What about plugins that run in a different thread (like the threshold
> adjuster)? Those would not retain the values set at the time of saving the
> project. Think that some of those plugins take the current image as a
> parameter. Wouldn't it be difficult to know what open plugin is acting on
> which image?
>
> Cheers
>
> Gabriel
>