Dear All,
Let me add a few observations in support of at least looking into
compression (even with some loss of information) and how that would
affect our results.
At LMB we've spent more than 200k£ over the past 3 years on buying very
fast parallel file systems for our cluster and less parallel systems for
medium-term storage. With 2 high-end microscopes potentially generating
2Tb per day and 60 people using them, these disks are now completely
saturated. People cleaning up their old data can always be improved, but
we're already implementing an automatic deletion of data on the fast
disks after 60 days. We're now spending another 100k£ on buying new
disks. In addition, we've spent more than 15k£ on removable USB drives
for long(er)-term storage over the past 18 months.
Obviously, a significant reduction in file size by compression would be
very welcome to lower the costs of storing our data (and ease of moving
it around all the time), irrespective of that cost in comparison with
the microscope. I would probably still be wary to delete the original
data, but if one could get virtually the same results with using say an
order of magnitude less space on the fast cluster-mounted disks, I would
definitely opt for storing the original data on (relatively cheap)
removable USB disks and just processing compressed data on the cluster.
For that, developments like Tom and Fred mentioned will be necessary and
useful.
Best wishes,
Sjors
On 06/16/2015 04:20 PM, Marin van Heel wrote:
> Dear All,
>
> For various reasons I don’t think this line of reasoning is very
> productive. The data compression to 8 or even 4 bits as has been
> suggested in this discussion can only lead to loss of data (see
> below). It may also represent poor management of the available EM
> resources.
>
> Point by point:
>
> A) Advanced cryo-EM equipment costs of the order of ~5000 AUs
> (Arbitrary Units: $/Eu/£) per day to own and operate, and will
> generate up to ~ 2Tbyte of cryo-EM data per 24h. The costs of storing
> this precious data for “eternity” will not exceed 100 AUs per day,
> that is, one or two percent of the tax-payers total investment in your
> data collection. NOT storing that raw data may NOT be a good idea for
> economic reasons alone (just in case you, for example, need to repeat
> the experiment to get the data back).
>
> B) Compressing all the raw data to save space can make sense as long
> as the compression is loss-less
> (https://en.wikipedia.org/wiki/Lossless_compression). The compression
> (after movie alignment) as suggested, however, may lead to a
> significant information loss.
>
> C) The dynamic range of a raw image is mainly determined by the
> low-frequency components of the data. Scaling the min-max densities
> from 0-255 for compression/truncation to 8 bit data, changes the data
> representation from image to image. The high-resolution information we
> are interested is has a contrast of probably less than 0.1% of the
> strong low-frequency components. The signal we are interested in is
> thus already much smaller than the discretisation error of 1:256 of
> the A-to-D conversion. That does not mean one will not be able to fish
> that information from the discretisation and Poisson noise in the raw
> data… But it will certainly suffer. The grey scales will change from
> image to image purely dependent on whether there is, for example, an
> ice crystal somewhere in the field of view. High-pass filtering will
> remove the large-scale details thus also increase the dynamic range
> available for the high-res frequency data components.
>
> D) Note that the fact that you manage to get a 3D structure out is no
> proof that you have not lost information. It is merely proof for the
> fact that there was enough left over to create a reasonable 3D that
> satisfies you.
>
> E) There are also other reasons for never deleting the original data
> such as validation! You may be challenged – as has happened in the
> recent past (PNAS 2013) - to show the original data set to prove it is
> what you claim it is and was collected on the instrumentation you
> claim it was taken on. (In the PNAS cases the original data has still
> not been released).
>
> F) What one can or wants to do with the raw data changes over time.
> Many new movie alignment algorithms have been proposed recently;
> access to exactly the same raw data is essential for validation of the
> new algorithms. (You may even get more out of your data!)
>
> G) The raw data characterizes the camera (and validates the data set
> as per E) and allow you to correct for its flaws
> (http://www.nature.com/srep/2015/150611/srep10317/full/srep10317.html). You
> may also want to see whether the camera itself deteriorated over time.
>
> H) Especially when the raw data are of some integer type, (and you are
> using data with a limited dynamic range), the data on disk will be
> written in a highly redundant fashion. You may then use loss-less
> compression algorithms to reduce the size of your data without
> suffering any information loss. You may always compress the data, you
> may never compromise on its information content!
>
> Cheers, Marin
>
> ========================================
>
> On 04/06/2015 00:15, Tom Houweling wrote:
>> What I meant is that Relion appears to have no problem reading 16 bit
>> and 8 bit formats, therefore converting to 32bit floating point
>> images should not be necessary.
>>
>> However, the verdict on loss of resolution reducing the data to 8
>> bits is still out. I’m motivated by conserving disk space.
>>
>> I’m currently reprocessing a good dataset that yielded a high
>> resolution structure. But this time I converted the aligned stacks of
>> 32bit per pixel to just 8 by the following method:
>>
>> 1)Calculate the mean and std. deviation
>> 2)Cutoff at +/- 3 std dev
>> 3)Set lowest value to 0 and highest to 255
>>
>> Tom
>>
>>
>>> On Jun 3, 2015, at 10:58 AM, Amedee des Georges
>>> <[log in to unmask] <mailto:[log in to unmask]>> wrote:
>>>
>>> Dear Tom,
>>>
>>> Did you see any decrease in resolution with 8bit vs 16? How did it
>>> look?
>>> It’s obviously an advantage to use 8bits for storage if it doesn’t
>>> decrease image quality significantly.
>>>
>>> Best,
>>>
>>> Amedee
>>>
>>> On Jun 3, 2015, at 1:44 PM, Tom Houweling
>>> <[log in to unmask] <mailto:[log in to unmask]>> wrote:
>>>
>>>> We have successfully processed MRC images and stacks in Relion that
>>>> were in 16 bit mode 6 and also in the non MRC sanctioned mode 5 (8
>>>> bit unsigned).
>>>>
>>>> —Tom
>>>>
>>>>
>>>>> On Jun 3, 2015, at 10:22 AM, Rémi Fronzes <[log in to unmask]
>>>>> <mailto:[log in to unmask]>> wrote:
>>>>>
>>>>> Dear All,
>>>>>
>>>>> Maybe a silly question but still worth asking.
>>>>> Is it a problem to extract and use in relion particles from 16bits
>>>>> MRC images (i.e. collected using EPU) ?
>>>>> Or do we have to convert the micrographs in 32 bits MRC format.
>>>>>
>>>>> Cheers
>>>>>
>>>>> Rémi
>>>>>
>>>>>
>>>>> Rémi Fronzes
>>>>> G5 biologie structurale de la sécrétion bactérienne, institut Pasteur
>>>>> CNRS UMR 3528, institut Pasteur
>>>>>
>>>>> Office: +33 (0)145688864
>>>>> Lab: +33 (0) 145688863
>>>>> Mobile: +33 (0) 688263992
>>>>> Email:[log in to unmask] <mailto:[log in to unmask]>
>>>>>
>>>>> 25 rue du Docteur Roux
>>>>> Bâtiment Metchnikoff, 3ème étage
>>>>> 75015 Paris, France
>>>>>
>>>>
>>>> --
>>>> Tom Houweling - QB3 Nogales Lab Computer Analyst @ Howard Hughes
>>>> Medical Institute
>>>> University of California Berkeley, 708D Stanley Hall, Berkeley, CA
>>>> 94720
>>>>
>>>>
>>>
>>
>> --
>> Tom Houweling - QB3 Nogales Lab Computer Analyst @ Howard Hughes
>> Medical Institute
>> University of California Berkeley, 708D Stanley Hall, Berkeley, CA 94720
>>
>>
>
>
>
>
> _______________________________________________
> 3dem mailing list
> [log in to unmask]
> https://mail.ncmir.ucsd.edu/mailman/listinfo/3dem
--
Sjors Scheres
MRC Laboratory of Molecular Biology
Francis Crick Avenue, Cambridge Biomedical Campus
Cambridge CB2 0QH, U.K.
tel: +44 (0)1223 267061
http://www2.mrc-lmb.cam.ac.uk/groups/scheres
|
