Daniel Russel wrote:
for example, if your magic number indicates big
endian, but the data are actually stored as little endian, your
output
will be messed up - but the reader works perfectly as it should do.
Currently, as far as I can tell, there is no checking of any magic
number in MRCReaderWriter. The only thing which controls the byte
ordering is the hack having to do with looking for excessively large
(and now excessively small) voxels.
The machine stamp ('magic number') is not reliably written into all
MRC
files, hence the workaround to detect byte-swapped files. MRC files
written out, on the other hand, should have correct machine stamps.