File Import Problem

Import and Export
1

Having a problem importing .mrc files. The exact error I’m getting is pasted below, but these are single frame images (checked the header information, pasted below the error message), so am at a loss what the problem might be.

Any suggestions?

The error I get is: [CPU: 170.5 MB] Traceback (most recent call last): File “cryosparc2_master/cryosparc2_compute/run.py”, line 82, in cryosparc2_compute.run.main File “cryosparc2_compute/jobs/imports/run.py”, line 557, in run_import_movies_or_micrographs assert shape[0] == 1, “Data file %s has more than 1 frame - import as movie instead” % (abs_path) AssertionError: Data file /data/neal/121119_SUV/cart_DOG/dog_31k_3s_-2_1a.mrc has more than 1 frame - import as movie instead"

RO image file on unit 1 : dog_31k_3s_-2_1a.mrc Size= 55622 K

                This is a byte-swapped file.

Number of columns, rows, sections … 3710 3838 1
Map mode … 2 (32-bit real)
Start cols, rows, sects, grid x,y,z … 0 0 0 3710 3838 1
Pixel spacing (Angstroms)… 1.266 1.266 1.266
Cell angles … 90.000 90.000 90.000
Fast, medium, slow axes … X Y Z
Origin on x,y,z … 0.000 0.000 0.000
Minimum density … 2.3105
Maximum density … 956.80
Mean density … 35.296
tilt angles (original,current) … 0.0 0.0 0.0 0.0 0.0 0.0
Space group,# extra bytes,idtype,lens . 0 0 0 0

 1 Titles :

Digital Micrograph™, GMS v 2.1f

2

Hi @mwaxham,
Thanks for reporting this.

I think what appears to be the case (and I’m not sure how this happened…) is that the .mrc files that you have are stored in “byte swapped” format, meaning that their “endianness” is backwards compared to standard files for x86 architecture machines (see https://en.wikipedia.org/wiki/Endianness). Were the images collected or processed on any exotic hardware? Servers that are not running x86 CPUs?

In this case, the header check tool you’re using is aware of endianness and reads files in either format, and therefore it correctly reports the size of the files. However, cryoSPARC’s .mrc reading functions are only built for little-endian files (as would be produced on x86 systems). In fact we’ve never before come across files that are in big-endian format!