In 2019 many authors, who cite the use of SPIDER in their research, utilize it for general image processing of electron microscopy data and for the development of new algorithms rather than routine 3D reconstruction. Since they regularly use other softwares which usually have data in MRC format it would be usefull if SPIDER could directly accept such data.
SPIDER can now load and create MRC format image and volume files. Just specify the full file name including the extension e.g. file.mrc or 'file.mrcs' anywhere that SPIDER requests a filename. For MRC stacked images/volumes you can use: 1@file.mrc. For prompts that request a stack template use: *@file.mrc. Examples.
Currently any newly created MRC file from SPIDER, unless you have altered the defaults with 'MD MRC' , will contain 32 bit floating point data and the first data point inside the file will be the upper left corner of the image and the bottem of a volume (UL L) which is the same as in SPIDER data files.
A few operations, especially on MRC stacks, may fail due to the lack of required header information such as the current file data range (min and max) or statistics (mean, std.) I suggest you use MRC format only when you wish to pass files to/from other software and continue to use SPIDER format within procedures, etc. due to many deficiencies in the MRC file format.
The most glaring of these deficiencies is that there is NO agreement for how the actual image/volume data is ordered within the file. As pointed out by the Collaborative Computational Project for Electron Cryo-microscopy (CCP-EM) :
The handedness of the data block is not well defined by the MRC2014 standard. Conventionally, many pieces of software have treated the data as right-handed, with the origin in the bottom left corner of a 2D image and the Z-axis pointing out of the screen.
However, this approach is not universal, and some packages treat the data block as left-handed. An example is FEI's EPU data acquisition software, which places the image origin in the top left, as documented in appendix C of the EPU User Manual.
Proposals for indicating the data handedness in the file header are under discussion, but for now, the only way to be sure of the handedness is to check the behaviour of each software package individually.
It appears Relion, ImageJ (Fiji), and now SPIDER expect that the origin and the first pixel in the data storage is at the upper left of the image. This ordering is more efficient for loading an image since file access is efficiently buffered. But IMOD and Chimera expect the origin and the first pixel to be at the lower left of the image.
Use of SPIDER with MRC/MRCS images for/from Relion
and Cryosparc is straight forward with regard to
origin/handedness as these softwares expect the same
'UL L' image origin and handedness as SPIDER.
Use of SPIDER with 'LL L' images for/from IMOD and
ImageJ is somewhat non-intuitive. SPIDER loads these
images as mirrored so that it can address pixel locations properly.
SPIDER has operations:
'CP FROM MRC',
'MRC HED',
'ST' with option '(D)ATA-ORIGIN', and
'MDMRC' with option '(D)ATA-ORIGIN',
which are useful in trying to process such images.
A posssible problem with use of SPIDER with MRC/MRCS images for/from Relion and Cryosparc is differences in recognizing and processing the images without current density statistics, especially in stacks. The 2014 format standard proposed the following convention: DMAX < DMIN, DMEAN < (smaller of DMIN and DMAX), and RMS < 0 each indicate that the quantity in question is not well determined. However Relion (and possibly Cryosparc do not accept these values sometimes.
Source: mrc.html Page updated: 17 Jan. 2020 ArDean Leith