[OpenSPIM] asynchronous writing of stacks bug?

[Alexis Maizel]

hi,
> Regarding the stack issue - you mentioned that it takes about 3 min to write 400 MB to disk, that might be an issue on the computer hardware side. A simple hard drive should give you around 100 MB/s, with smaller data packages it might be less but 3 min sounds way to slow. Can you reduce the data rate and see if that helps?For example by reducing the frame rate or using binning while keeping the frame rate constant. Or if you can, try an SSD drive or a RAID system for data acquisition. Streaming data can also be very sensitive to background activities, such as virus scanners, cloud syncing, update scanners.

I do not think that the problem comes from the hard drive:
1) reducing the file size by a factor of 2 or 4 (binning) did not make the writing to disk faster. With the asynchronous writing ON, the planes are always written to disk in a peppered manner between two consecutive time lapse, with the last image(s)  written right before the next time point.

2) When  asynchronous writing os OFF (i-e writing to disk is occurring immediately, which should be a good readout of the hard drive speed) the stacks are written in about 20sec (for ~200Mb)

With my best regards,

Alexis


> Best regards,
> Michael
> 
> 
> On Aug 14, 2013, at 10:20 AM, Alexis Maizel <Alexis.Maizel at cos.uni-heidelberg.de> wrote:
> 
>> Hi Jan,
>> 
>>> BTW the images are not in focus and you seem to collect quite a bit of laser speckles. Clearly a sign for a bad emission filter or that your laser needs a clean-up filter.
>> 
>> Yes, the laser does need a clean up filter quite a bit of green light in it, especially at low power; it is ordered. The emission filter (http://www.semrock.com/FilterDetails.aspx?id=FF03-525/50-25) seems right, no? 
>> 
>> As for focus, this is the best we could get so far :-/
>> Our LS is ~10µm thick and nicely shaped. The excitation lens is a Nikon CFI FLUOR 10x/0.30.
>> Do you have suggestions to improve the focus?
>> 
>> With my best regards,
>> 
>> Alexis
>> 
>> 
>> On 14 Aug 2013, at 10:11, Jan Huisken <huisken at mpi-cbg.de> wrote:
>> 
>>> Hi Alexis,
>>> 
>>> this is clearly a camera issue. Sometimes this goes along with missing or partial frames. We have seen it happening when something goes wrong with the spooling, e.g. when the hard drive is too slow or too full or too many files in one folder.
>>> 
>>> 
>>> Best
>>> Jan
>>> 
>>> Dr. Jan Huisken
>>> MPI of Molecular Cell Biology and Genetics
>>> Pfotenhauerstr. 108, 01307 Dresden, Germany
>>> 
>>> On Aug 13, 2013, at 8:14 PM, Alexis Maizel 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
>>> 
>> 
>> _______________________________________________
>> OpenSPIM mailing list
>> OpenSPIM at openspim.org
>> http://openspim.org/mailman/listinfo/openspim
> 
> _____________
> 
> Michael Weber
> PhD Student, Huisken lab
> Max Planck Institute of Molecular Cell Biology and Genetics
> Pfotenhauerstrasse 108, 01307 Dresden
> Tel. 0049 351/2102837
> 
> http://www.mpi-cbg.de/huisken
> 
> _______________________________________________
> OpenSPIM mailing list
> OpenSPIM at openspim.org
> http://openspim.org/mailman/listinfo/openspim

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 363 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://openspim.org/pipermail/openspim/attachments/20130814/614a38d3/attachment.sig>