[OpenSPIM] asynchronous writing of stacks bug?

[Pavel Tomancak]

Hi Alexis,

That is very strange. I have never seen that. We made some acquisitions today and nothing like that was going on. Its obviously a serious issue. Does it happen only when you have the asynchronous writing enabled? I assume you are running on Windows 7.

All the best

PAvel

-----------------------------------------------------------------------------------
Pavel Tomancak, Ph.D.

Group Leader
Max Planck Institute of Molecular Cell Biology and Genetics
Pfotenhauerstr. 108
D-01307 Dresden				Tel.: +49 351 210 2670
Germany						Fax: +49 351 210 2020
tomancak at mpi-cbg.de
http://www.mpi-cbg.de
-----------------------------------------------------------------------------------



On Aug 13, 2013, at 8:14 PM, Alexis Maizel <Alexis.Maizel at cos.uni-heidelberg.de> wrote:

> Hi,
> 
> I have noticed that when acquiring stacks during a time lapse and writing them to disk, using the 'asynchronous writing' option, the order in which the individual images are laid into the stack is imprecise. What I mean is that an image obviously in the middle of the stack is shifted toward the end. I did not observed a fixed pattern, except that usually the first 15-20 planes are in the right order and the mess is a the end.
> 
> I have carefully observed and the problem does not come from the stage 'going back and forth' during acquisition. It is upon writing to the disk that the problem seems to occur. Also I have noticed that it takes quite a long time (up to 3 minutes) to write to disk a ~400Mb stack. 
> 
> You can see more precisely what I am talking about by looking at two representative stacks: http://dl.dropbox.com/u/484859/Stacks.zip
> 
> With my best regards,
> 
> Alexis
> 
> _______________________________________________
> OpenSPIM mailing list
> OpenSPIM at openspim.org
> http://openspim.org/mailman/listinfo/openspim

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://openspim.org/pipermail/openspim/attachments/20130814/5ec66939/attachment-0002.html>