Re: Image Processing Software

[Daniel James White]

> Hi Andreas,
>
> On Sep 30, 2011, at 7:02 AM, CONFOCALMICROSCOPY automatic digest system wrote:
>
>> Date:    Thu, 29 Sep 2011 17:41:20 -0400
>> From:    Andreas Bruckbauer <[hidden email]>
>> Subject: Re: Image Processing Software
>>
>> I find the look and feel of imageJ ok, but a serious limitation is that th=
>> e image processing pipeline is not saved with the image and often there is =
>> no undo available.
>
> Undo is a problem, and I think the imageJ2 guys are working on that…?
>
> ...but for having a reproducible pipeline, this is not problem,
> so long as you record your commands with the macro recorder.
> Saving this as a macro is no problem…. but
> the macro is not saved in the result image….
>
> Maybe we could find a way to add the macro to the tiff header or ome metadata….
>
> We would have to listen to each image window and capture all the commands executed on it,
> and also when new image windows are generated also record how they were made…
> and probably some more fiddly cases…
>
> This might require a whole new framework, and I dont know what the
> imageJ2 guys have in mind there…regarding undo etc. #
>
>
>> It is very interesting that Bitplane advertises the Imar=
>> isXT function with: "The plugin allows the exchange of 3D images between Im=
>> aris and ImageJ, thus enabling the use of the powerful image processing abi=
>> lities of ImageJ on Imaris datasets".=20
>
> Nice eh!
>
> Dan
>
>
>>
>> best wishes
>>
>> Andreas
>

Dr. Daniel James White BSc. (Hons.) PhD

Leader - Image Processing Facility,
Senior Microscopist,
Light Microscopy Facility.

Max Planck Institute of Molecular Cell Biology and Genetics
Pfotenhauerstrasse 108
01307 DRESDEN
Germany

[phone] (German Mobile)
[phone] (Work phone at MPI-CBG)
[phone] (Fax MPI-CBG LMF)
chalkie666 Skype
http://www.bioimagexd.net  BioImageXD
http://fiji.sc                                        Fiji -  is just ImageJ (Batteries Included)
http://www.chalkie.org.uk                Dan's Homepages
https://ifn.mpi-cbg.de  Biopolis Dresden Imaging Platform (BioDIP)
dan (at) chalkie.org.uk
( white (at) mpi-cbg.de )

[ctrueden]

Hi Dan & everyone,

>> I find the look and feel of imageJ ok, but a serious limitation is that
the
>> image processing pipeline is not saved with the image and often there is
>> no undo available.
>
> Undo is a problem, and I think the imageJ2 guys are working on that…?

Describing undo as a "problem" is indeed accurate. In general it is
difficult, especially as the scope and functionality of a program expands.
Since most operations are not invertible, the program must essentially keep
"snapshots" of the workspace as things change. Increasingly large image data
and metadata means these snapshots can take up a LOT of space (much more
than available RAM), so a system is needed to cache old program states to
"scratch space" on disk, recalling them as needed when the user requests an
undo. I believe this sort of approach is how Photoshop works, but for large
multidimensional data it can become very expensive.

In short, we have thought about it a lot, but it is not yet implemented. And
it will be a substantial but doable project. The good news is that event
infrastructure is already in place for macro recording and tracking data
provenance (which are very related to undo/redo), so we are halfway there.
But realistically, full support for multiple undo may not make it into the
initial ImageJ 2.0 release.

> Maybe we could find a way to add the macro to the tiff header or ome
metadata….

Yes, in general, the only 100% complete way to record data provenance is to
save the actual code used to perform the computation. Otherwise, if you
merely record the name of the algorithm and its parameters, results might
differ on reexecution with a different version of the software (though you
can record versions too, of course). Actually, even saving the actual code
is not 100%, because the results might differ based on system architecture,
operating system changes, etc.

That said, in practice, embedding the version of ImageJ & plugins
responsible for generating the output, together with the recorded script
that would reproduce it, should be pretty reliable in most circumstances.
Hopefully we can find a place for this in the OME metadata model, and any
other models the community is using.

> This might require a whole new framework, and I dont know what the
> imageJ2 guys have in mind there…regarding undo etc.

Hopefully the above helps clarify. We would be happy to discuss further if
people disagree or have additional requirements!

Regards,
Curtis Rueden
ImageJ2 lead developer
http://imagejdev.org/


On Fri, Sep 30, 2011 at 2:34 AM, daniel white <[hidden email]> wrote:

> > Hi Andreas,
> >
> > On Sep 30, 2011, at 7:02 AM, CONFOCALMICROSCOPY automatic digest system
> wrote:
> >
> >> Date:    Thu, 29 Sep 2011 17:41:20 -0400
> >> From:    Andreas Bruckbauer <[hidden email]>
> >> Subject: Re: Image Processing Software
> >>
> >> I find the look and feel of imageJ ok, but a serious limitation is that
> th=
> >> e image processing pipeline is not saved with the image and often there
> is =
> >> no undo available.
> >
> > Undo is a problem, and I think the imageJ2 guys are working on that…?
> >
> > ...but for having a reproducible pipeline, this is not problem,
> > so long as you record your commands with the macro recorder.
> > Saving this as a macro is no problem…. but
> > the macro is not saved in the result image….
> >
> > Maybe we could find a way to add the macro to the tiff header or ome
> metadata….
> >
> > We would have to listen to each image window and capture all the commands
> executed on it,
> > and also when new image windows are generated also record how they were
> made…
> > and probably some more fiddly cases…
> >
> > This might require a whole new framework, and I dont know what the
> > imageJ2 guys have in mind there…regarding undo etc. #
> >
> >
> >> It is very interesting that Bitplane advertises the Imar=
> >> isXT function with: "The plugin allows the exchange of 3D images between
> Im=
> >> aris and ImageJ, thus enabling the use of the powerful image processing
> abi=
> >> lities of ImageJ on Imaris datasets".=20
> >
> > Nice eh!
> >
> > Dan
> >
> >
> >>
> >> best wishes
> >>
> >> Andreas
> >
>
>
> Dr. Daniel James White BSc. (Hons.) PhD
>
> Leader - Image Processing Facility,
> Senior Microscopist,
> Light Microscopy Facility.
>
> Max Planck Institute of Molecular Cell Biology and Genetics
> Pfotenhauerstrasse 108
> 01307 DRESDEN
> Germany
>
> [phone] (German Mobile)
> [phone] (Work phone at MPI-CBG)
> [phone] (Fax MPI-CBG LMF)
> chalkie666                                      Skype
> http://www.bioimagexd.net       BioImageXD
> http://fiji.sc                                  Fiji -  is just ImageJ
> (Batteries Included)
> http://www.chalkie.org.uk               Dan's Homepages
> https://ifn.mpi-cbg.de                  Biopolis Dresden Imaging Platform
> (BioDIP)
> dan (at) chalkie.org.uk
> ( white (at) mpi-cbg.de )
>

[Birgit M=?UTF-8?Q?=C3=B6ller?=]

>Hi Dan & everyone,

Hi everybody,
I would like to make a short note on the problem of implementing undo functionality and processing pipeline documentation.

>[...]
>>> image processing pipeline is not saved with the image and often there is
>>> no undo available.
>>
>> Undo is a problem, and I think the imageJ2 guys are working on that…?
>
>Describing undo as a "problem" is indeed accurate. In general it is
>difficult, especially as the scope and functionality of a program expands.
>Since most operations are not invertible, the program must essentially keep
>"snapshots" of the workspace as things change. Increasingly large image data
>and metadata means these snapshots can take up a LOT of space (much more
>than available RAM), so a system is needed to cache old program states to
>"scratch space" on disk, recalling them as needed when the user requests an
>undo. I believe this sort of approach is how Photoshop works, but for large
>multidimensional data it can become very expensive.
>
>In short, we have thought about it a lot, but it is not yet implemented. And
>it will be a substantial but doable project. The good news is that event
>infrastructure is already in place for macro recording and tracking data
>provenance (which are very related to undo/redo), so we are halfway there.
>But realistically, full support for multiple undo may not make it into the
>initial ImageJ 2.0 release.
>
>> Maybe we could find a way to add the macro to the tiff header or ome
>>metadata….

>Yes, in general, the only 100% complete way to record data provenance is to
>save the actual code used to perform the computation. Otherwise, if you
>merely record the name of the algorithm and its parameters, results might
>differ on reexecution with a different version of the software (though you
>can record versions too, of course). Actually, even saving the actual code
>is not 100%, because the results might differ based on system architecture,
>operating system changes, etc.

>That said, in practice, embedding the version of ImageJ & plugins
>responsible for generating the output, together with the recorded script
>that would reproduce it, should be pretty reliable in most circumstances.
>Hopefully we can find a place for this in the OME metadata model, and any
>other models the community is using.

>> This might require a whole new framework, and I dont know what the
>> imageJ2 guys have in mind there…regarding undo etc.

>Hopefully the above helps clarify. We would be happy to discuss further if
>people disagree or have additional requirements!

Implementing an unlimited undo functionality would indeed be great, but it is of course difficult and a quite elaborate task, as Curtis mentioned above. We have already done several steps in the second direction of processing pipeline documentation. In particular, we have a Java library supporting the automatic documentation of data analysis processes in terms of saving applied operators, parameter settings and software versions together with generated result data. The basic concept is general and independent of ImageJ, but we also have a set of ImageJ plugins relying on that concept, i.e. allowing for documenting the analysis processes in which they are involved. Unfortunately to integrate the documentation concept into existing ImageJ 1.0 plugins would require to wrap all the plugins. However, integrating the concept into upcoming ImageJ 2.0 will be much easier and requires only slight modifications of the ImageJ core as annotations and the new mechanism of plugin invocation simplifies a lot. There is no need to re-design the whole framework. We demonstrated this integration earlier, if you are interested in the programming details take a look here

http://imagejdev.org/pipermail/imagej-devel/2011-May/000381.html
http://imagejdev.org/pipermail/imagej-devel/2011-May/000384.html

or visit our webpage(s) to get the fundamental ideas of our approach:

http://www.informatik.uni-halle.de/alida/
http://www.informatik.uni-halle.de/mitobo/

We are also very interested in getting to know in how far such a documentation framework might be of interest for you in your daily work with ImageJ, and what your requirements would be regarding such a functionality. So any comments or discussions are highly welcome!

>Regards,
>Curtis Rueden
>ImageJ2 lead developer
>http://imagejdev.org/

Best regards,
Birgit Moeller
Pattern Recognition and Bioinformatics Group
Institute of Computer Science
Martin Luther University Halle-Wittenberg

[Antoinette]

Image processing software can be easy-to-find in some open source thirs party with the complete guide on sample image editing functions methods and demo codes. Besides, can anyone recommend me an image thumbnail creation application for .net framework?