Posted by
Mario Emmenlauer-3 on
Nov 10, 2014; 7:13pm
URL: http://imagej.273.s1.nabble.com/How-does-Multiview-Reconstruction-compare-to-Zeiss-tp5010290p5010361.html
Hi Stephan,
thanks for the additional input! A few questions below:
On 10.11.2014 15:59, Stephan Preibisch wrote:
> I am just back from vacation and just wanted to add my thoughts here. My multi-view reconstruction software allows the registration based on beads or/and sample features (spotty things within the sample like nuclei, but can be any kinds of bright or dark spots). Right now, there is no “classical” intensity correlation method as it is very slow as affine transformation models need to be estimated to get it right. But the plan is to add it at some point, the software framework supports it.
>
> Regarding the dual sided illumination. From my experience at the EMBO course, it is not advisable to do online dual side fusion. For most samples, the aberration introduced by the specimen itself is significant (I saw around 5-20 pixels) and you will introduce blur if you do online dual sided fusion. Ideally treat them as views that need to be registered as any other views. I am in the process of writing a howto do this right, but it will take more time.
So is the Zeiss Zen software doing "online dual side fusion"? Then it
would be highly preferable to follow your newly-written guide instead
of continuing to use the Zeiss Zen dual side fusion...
> There is an old (plugins > SPIM Registration) and a new version (plugins > Multiview Reconstruction, add it by activating the BigDataViewer update site in Fiji). The old one is completely cluster processable, Pavel sent the link. However, the software itself is outdated by now as it only supports bead-based registration. The new version is much more flexible, powerful, and integrated into the BigDataViewer. Cluster processing already works for the new one, but only for fusing/deconvolving the data. The remaining problem here is that the new version is based on an XML file describing the dataset (same as the BigDataViewer), so when this XML file is edited by segmenting features or writing the affine matrices, some additional software is required to merge the results from different timepoints when processed in paralell. This will be available most likely in December. That’s why it works for fusing, as the XML is only read, not written.
December would be an good time line for us, please keep me posted, and
thanks for your nice work!
> The registration quality using beads should be somewhat comparable for my old plugin, new plugin, and the zeiss software as they are all based on the algorithm, just implemented differently (
http://www.nature.com/nmeth/journal/v7/n6/full/nmeth0610-418.html <
http://www.nature.com/nmeth/journal/v7/n6/full/nmeth0610-418.html>). On a side note, my new plugin also supports CUDA processing. However, the new plugin allows additional registration using affine models based on sample features, i.e. the new plugin is capable of somewhat correcting for sample-induced aberrations (can be done in a second step after the beads registration or only using sample features). Therefore it does produce better results than my old plugin (and I think also the Zeiss software) as they do not support that second registration step.
How much does the CUDA speed up the process of the full fusion with all
steps, start to end (including beads segmentation, bead registration,
fine registration and deconvolution/fusion)?
I have never tried this myself, so if you can post some rough numbers
and some specs from your test machine I would be happy. Especially, I would
be curious if its better to do everything on one powerful CUDA-enabled high-
memory-machine, or better to employ hundreds of cluster nodes? We currently
aim for the cluster, unless you advise that one CUDA-machine might out-
perform many cluster nodes (also because it avoids network transfer of the
files to the cluster)?
All the best and thanks,
Mario
> If you have more questions I am happy to answer.
>
> Have a great day,
> Stephan
>
> ---
>
> Dr. Stephan Preibisch
> HFSP Fellow
> Robert H. Singer / Eugene Myers lab
>
> Albert Einstein College of Medicine / HHMI Janelia Farm / MPI-CBG
>
> email:
[hidden email] <mailto:
[hidden email]> /
[hidden email] <mailto:
[hidden email]> /
[hidden email] <mailto:
[hidden email]>
> web:
http://www.preibisch.net/ <
http://fly.mpi-cbg.de/preibisch>
>> On Nov 5, 2014, at 7:11 , Mario Emmenlauer <
[hidden email]> wrote:
>>
>> Dear Pavel,
>>
>> thanks a lot for the detailed and helpful answer! Below more:
>>
>> On 05.11.2014 11:07, Pavel Tomancak wrote:
>>>> I'm trying to automate the workflow from a Zeiss Lightsheet Z.1 to
>>>> the registered/fused/deconvolved volume. Previously we used the Zeiss
>>>> software, but I understand that this can not easily be scripted and/or
>>>> distributed on a cluster?
>>>>
>>>> What is the best replacement that is scriptable and cluster-runnable?
>>>
>>> In addition to what you already found, there is also this web page
>>>
>>>
http://fiji.sc/SPIM_Registration_on_cluster>>>
>>> which details how to run Fiji's SPIMage processing pipelines on a cluster (registration, fusion, deconvolution and HDF5 saving).
>>
>> I will check this out, thanks!
>>
>>
>>>> I've found
http://fiji.sc/Multiview-Reconstruction (MR) and it looks
>>>> very promising, but how does it exactly compare to the Zeiss software?
>>>
>>> We worked very closely with Zeiss when developing the Fiji plugins. The Zeiss software is to a large degree based on our published research:
>>>
>>> Preibisch S., Saalfeld S., Schindelin J., Tomancak P. (2010) Software for bead-based registration of selective plane illumination microscopy data. Nature Methods 7:418-419
>>>
>>> In ZEN it has been implemented by Zeiss developers independently and since it is not published and the source code is not available I cannot say how similar it is to our implementation when it comes to details. The general approach is similar. As far as I know, Zeiss software does not use global optimisation.
>>>
>>>> I understand Zeiss does not require beads, MR does?
>>>
>>> Zeiss software can do the reconstruction with and without beads. Similarly the Fiji plugins can either use beads or segmentation in the sample (e.g. nuclei) to achieve the registration. Sometimes it is necessary to use both, first bead-based followed by nuclei based registration. For example look here
>>>
>>>
http://openspim.org/TriboliumExtraembryonicMembranes>>
>> Thanks, this is very enlightening and helpful. I will check
>> this in more detail and see how we can profit from segmentation
>> versus beads...
>>
>>
>>>> And our workflow
>>>> uses DualSide Fusion, is that supported with MR?
>>>
>>> The DualSide Fusion in done internally in ZEN. We simply start our pipelines with the fused data (i.e. left and right lightsheet merged). It is important to save the data from ZEN as one file per view per time point. This is currently the only dataset that Fiji Bioformat importer can reliably open. Efforts to make it more robust are underway.
>>
>> My biologists report that the DualSide Fusion with the Zeiss Zen
>> Software is sometimes done while recording, but this only works for
>> small Z-stacks for them, because for big stacks it takes the computer
>> too long and imaging gets delayed. So I understand that this is a
>> bottleneck for us - did you get this solved somehow?
>>
>>
>>>> Finally, how do they
>>>> compare in terms of quality of the result, is one or the other software
>>>> "better" in any aspect by a reasonable margin, or do they compare on
>>>> par?
>>>
>>> Ok, this is very hard to answer. We are academic researchers and of course we believe that our approach is the best ;-). We have not done rigorous benchmarks against Zeiss software. Anecdotally, on some datasets Fiji works better on others ZEN. You will have to try it for yourself.
>>>
>>> Here are some additional resources that you may find useful.
>>>
>>> A book chapter describing the SPIMage processing pipeline formally, tutorial style (download it from here
http://www.mpi-cbg.de/nc/research/research-groups/pavel-tomancak/papers.html)
>>> Schmied C., Stamataki E., Tomancak P. (2014) Open-source solutions for SPIMage processing. Methods Cell Biol., 123, pp. 505-529
>>>
>>> Multi-view deconvolution paper and software (this is, I think, unrelated to the Zeiss deconvolution approach - an alternative).
>>> Preibisch S., Amat F., Stamataki E., Sarov M., Myers E., Tomancak P. (2013) Efficient bayesian multi-view deconvolution Nature Methods, 7, 418–419
http://arxiv.org/abs/1308.0730>>>
>>>
http://fiji.sc/Multi-View_Deconvolution>>>
>>> visualisation solution for multi-view SPIM data - BigDataViewer (to be published soon)
>>>
http://fiji.sc/BigDataViewer>>>
>>> and finally lots of useful information can be found on the OpenSPIM wiki, particularly in the section dealing with the EMBO course on light sheet microscopy that we organised in Dresden this summer
>>>
>>>
http://openspim.org/EMBO_practical_course_Light_sheet_microscopy>>>
>>> Don't hesitate to contact us if you have further questions.
>>
>> I've read already a bit on OpenSPIM, it looks very interesting! Do
>> I understand correctly that OpenSPIM does not develop or host software
>> for registration/fusion/deconvolution itself, the software recommended
>> at OpenSPIM is basically the same Fiji modules you mention also above?
>> It makes perfect sense, but I'm trying to make sure I'm not overlooking
>> any (reasonably good) software. The only other software for fusion I
>> could find is "Spatially-Variant Lucy-Richardson Deconvolution for
>> Multiview Fusion of Microscopical 3D Images" by Maja Temerinac-Ott et
>> al, see
http://lmb.informatik.uni-freiburg.de/Publications/2011/BRT11/>>
>> Is there any other (commercial or non-commercial) option you would be
>> aware of?
>>
>> All the best and thanks a lot,
>>
>> Mario
>>
>>
>>
>> --
>> Mario Emmenlauer BioDataAnalysis Mobil: +49-(0)151-68108489
>> Balanstrasse 43 mailto: mario.emmenlauer * unibas.ch
>> D-81669 München
http://www.biodataanalysis.de/>>
>> --
>> ImageJ mailing list:
http://imagej.nih.gov/ij/list.html>
>
> --
> ImageJ mailing list:
http://imagej.nih.gov/ij/list.html>
--
A: Yes.
> Q: Are you sure?
>> A: Because it reverses the logical flow of conversation.
>>> Q: Why is top posting annoying in email?
Mario Emmenlauer BioDataAnalysis Mobil: +49-(0)151-68108489
Balanstrasse 43 mailto: mario.emmenlauer * unibas.ch
D-81669 München
http://www.biodataanalysis.de/--
ImageJ mailing list:
http://imagej.nih.gov/ij/list.html