16 Jul
2008
16 Jul
'08
10:16 a.m.
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.
Ben
--
ben@salilab.org http://salilab.org/~ben/
"It is a capital mistake to theorize before one has data."
- Sir Arthur Conan Doyle