Hi,
The read-support for MRC mode 12 is much welcomed. Are there plans to implement similar float16 write-support in cryoSPARC?
Cheers,
Yang
Hi,
The read-support for MRC mode 12 is much welcomed. Are there plans to implement similar float16 write-support in cryoSPARC?
Cheers,
Yang
@leetleyang Please can you describe a use case for this feature and how, in terms of the user interface, would you like to see it implemented?
Thanks @wtempel. Yes, the writing of motion-corrected summed micrographs and/or particle image stacks in float16 would a) halve the amount of disk space required to store them, and b) potentially speed up data retrieval.
In terms of implementation, an Advanced Mode toggle that is off (i.e. set to float32) by default would make sense. Perhaps float16 data could be marked a subtly different colour when dragging as input for subsequent jobs to make it easier to differentiate visually.
Intermediate data is often fourier cropped aggressively and then surplus to requirements once initial curation is complete. Yet the tendency is to hold on to it just in case. Given typical electron counts in SPA experiments, it could be argued that the precision afforded by float32 is overkill in many cases.
FWIW. Using EMPIAR-11057 as a test case, the reconstructions from shiny particles in float16 vs float32 were identical in terms of GSFSC and map quality (FSC 0.143 ~2.1Å), suggesting that float16 may be appropriate in more cases than not.
Just a thought.
Cheers,
Yang
Most folks I know are frequently space-constrained. 1/2 space savings are not that much, but it would still make my life easier!
Note that beyond making particle stacks smaller, it could also increase the chance that a stack can reside entirely in the Linux IO cache. (I think anyway, as long as you don’t read into float32 in memory).