Hi Albion, When you open a map in Chimera you can see what origin and voxel size (= grid plane spacing) is being used with volume dialog menu entry "Features / Origin and Scale" (Chimera version 1.2199 or later). You can change the values and the Chimera display will update, though the map header will not be modified. You can save a new MRC 2000 format map using Chimera volume dialog menu entry File / Save As.... The question of how various software packages position density maps in xyz coordinate space when they are opened is complex. It is of course important if you want a PDB model to properly fit into the map when you open both the map and model in a visualization program. Here are a few of the complexities. You are interested in CCP4 format. In fact there are 3 almost identical formats called CCP4, MRC, and MRC 2000. Although there are descriptions of the formats online, for example, here is info about the header of MRC 2000, http://ami.scripps.edu/prtl_data/mrc_specification.htm none of them are very rigorously documented. One complexity is that CCP4 format describes map placement with integer offsets (nrstart, ncstart, nsstart) and therefore cannot position the map at an arbitrary floating point origin. This works fine for crystallographic maps when just accomodating files containing submaps. With EM maps you may want floating point origins, for instance to align maps of a sectioned specimen. The MRC 2000 format adds floating point XYZ origin fields in extra space the file header which is otherwise almost identical to CCP4. My guess would be that O ignores the MRC 2000 xyz origin because it is oriented towards crystallographic maps. Chimera uses the MRC 2000 xyz origin if the header identifies the file as MRC 2000, otherwise it uses the CCP4 integer offsets. It tries to handle both the EM and crystallography origins. I'm not sure what PyMol does. Another complexity is that CCP4 (and MRC, MRC 2000) allow the three axes of the data matrix in the file (called columns, rows and sections meaning fast, medium, and slow axes) to be treated as any permutation of the x, y and z axes when displayed in visualization software. Some software ignores that possibility which leads to incorrect assignment of the x, y, and z axes. Chimera handles the permutations as they were intended. I do not know how O or PyMol handle these. Most maps use a standard axis order so software that ignores axis permutation only runs into trouble on some files. Some software always puts the middle of the data set at xyz = (0,0,0) and ignores any origin information. Another complexity is avoiding half-voxel origin errors. The voxel is the grid cell (a 3-d box) associated with a specific data matrix value. The matrix value may be treated as a sampling of continuous data at the center of the voxel. There is a question of whether the above origin specifications position the center of the voxel or a corner of the voxel. Different software may produce alignments that vary by half of the grid spacing because of different interpretations. Chimera considers the origin to correspond to the center of voxel with grid index 0,0,0. To make more trouble, some map files have uninitialized data in the parameters defining origin, and many EM data sets have meaningless values for the cell size (often 1.0) that determines grid plane spacing. In some cases Chimera will decide that the origin or grid spacing (e.g. negative cell size) is garbage and just place the origin at xyz = (0,0,0) with grid spacing equal to 1.0 along each axis. To know exactly how Chimera reads CCP4, MRC and MRC 2000 look at the Python code for the file reader chimera/share/VolumeData/mrc/mrc_format.py included in all Chimera distributions. There is a "CryoEM Standards Task Force" involving many groups that is currently trying to produce and document answers to just the question you ask. Here is a web page that is under design for submitting conventions on how various software packages display EM maps. http://conventions.cnb.uam.es/ It currently does not contain any data for specific packages because the forms for entering the data are still under development and will take some months before it is ready for use. Tom

Hi Albion, An origin of (-224,-224,-224) does not seem consistent with the MAPMAN header output you sent. From that I suspect that you have an MRC 2000 file with xorigin, yorigin, and zorigin set and MAPMAN does not display those header values. Here are two approaches to see the MRC header values. You can add a few lines to chimera/share/VolumeData/mrc/mrc_format.py to print all the header values that Chimera reads when the MRC map is opened. After the lines v = self.read_header_values(file, file_size) self.check_header_values(v, file_size, file) self.header = v # For dumpmrc.py standalone program. add the additional lines: for key, value in sorted(v.items()): print key, value Then restart Chimera and open the map and use menu entry Favorites / Reply Log to see the printed header value. If you see a "zorigin" value then you have an MRC 2000 map. My guess is you have it and its value is -224. The scale_and_skew() call you noted in mrc_format.py just multiplies the integer origin by the voxel size and applies a skewing transformation if the cell angles are not 90 degrees. (They are 90 for your map.) The alternate approach is to use unix utility "od" (on Linux or Mac) to print the binary header as ints or floats depending on the values in the header you are interested in. Tom