MTZ files are not maps.  They can usually be converted into maps, but 
that depends on the type of information they contain. Coot lets you load 
an mtz and immediately view a map, but only because it internally picks 
the coefficients that you probably want to use and then internally 
executes an inverse Fourier transform.  To get a map you can access 
voxel by voxel you will need the CCP4 program "FFT":
http://www.ccp4.ac.uk/html/fft.html

Once you have a map file, you can convert it to text using the CCP4 
program MAPDUMP:
http://www.ccp4.ac.uk/html/mapdump.html
or perhaps MAP2NA4
http://www.ccp4.ac.uk/html/maptona4.html

However, both of these output only a few significant digits, which 
invariably introduces round-off error.  Some may argue that the extra 
digits are not "significant" anyway, but round-off error is an insidious 
beast, and once introduced it never goes away.  If you don't believe me, 
try rotating a PDB file of lysozyme through 100 full 360-degree 
rotations in 1 degree steps with PDBSET.  You will find that you do not 
end up with the same structure you started with!  It is RMS 0.1 A 
different, with some atoms as much as 1 A out of place.  This is not a 
bug in PDBSET, it arises from the round-off error in the 3rd 
"significant digit" of the coordinates accumulating with each round-off 
event.

But I digress.  The point is that in situations where you are going to 
go back-and-forth between map an mtz more than once, or if you simply 
don't know the magnitude of error that you are dealing with (a common 
situation), then I recommend keeping round-off error to a minimum.

    Internally, CCP4 maps are stored as 4-byte floats, which have about 
seven significant base-10 digits.  The full file format definition is here:
http://www.ccp4.ac.uk/html/maplib.html

Personally, I tend to read map values with the unix binary dump program 
"od", which can be made to read 4-byte floats.  It is simply a matter of 
skipping the header, which is easily done by using MAPDUMP to tell you 
how many grid points are in the file and subtracting 4* that number of 
bytes from the file size.  I wrote a little jiffy script for converting 
a CCP4 *.map file into a PDB file with the density printed into the B 
factor column here:
http://bl831.als.lbl.gov/~jamesh/map_noise/scripts/map2pdb.com
This script does introduce round-off error, but you can modify it as you 
see fit.  You will find, however, that the PDB file produced this way is 
pretty huge.

I should warn you that you will find that the "nearest" map grid point 
is not a very good approximation of a given point of interest (such as 
the center of an atom).   What you might want to do is interpolate 
between nearby map grid points, possibly even doing a cubic spline 
interpolation in three dimensions.  This feature cannot be found in the 
CCP4 suite, but is available in the RAVE suite from Uppsala Software 
Factory as the program MAPMAN:
http://xray.bmc.uu.se/usf/mapman_man.html
use the "peek" function in that program.

All that said, I caution you that integrating a "volume" from map values 
is in general not a very good idea.  More properly, the integral of 
electron density over space is a "charge", and such integrals are very 
sensitive to offsets.  Offsets are dangerous because most maps are 
calculated to have the sum all grid point values equal to zero.  This is 
simply because the F000 structure factor, which represents this sum, was 
not measured.  So, if you add "1" to all your map voxels, your integral 
immediately becomes "n" times higher, where "n" is the number of grid 
points.  Yes, difference maps are supposed to be centered on zero, but 
to what precision?  You need F000 to be sure.  One way of estimating 
F000 was published recently:
http://www.pnas.org/content/111/1/237.long

However, when integrating density you also have problems with how far 
away from your point of interest you should integrate.  Too far and you 
pick up a lot of noise, but too close and you get systematic bias.

Personally, I think the best way to integrate a map is by using 
occupancy refinement.  Essentially, if you have a noisy curve and you 
want to integrate it, fitting a smooth function to that curve and then 
integrating the curve itself is often a very powerful noise filter.  The 
calculated form factor for an atom has a well-defined integral (the 
atomic number), it "automatically" defines the vacuum level of the map 
by being zero far from the atomic center, it "automatically" subtracts 
the density of neighboring atoms (if they are modeled in), and also 
down-weights more distant voxels by an appropriate amount.  That is, the 
optimum noise filter is generally the same shape as the signal of 
interest (sometimes called a Wiener filter, see the Numerical Recipes 
book).  So, if you fit a bunch of hydrogen atoms into your mystery 
density (perhaps keeping the rest of the model fixed if you can) then 
the sum of all those hydrogen occupancies is a very good estimate of the 
number of electrons in the feature.  What is the error bar?  Try 
jiggling the rest of the molecule and re-refining the occupancies.  That 
is at worst a lower bound for the total error.  Do this 5-10 times with 
different random number seeds and you will have a handle on the RMS 
variation in your "measurement" of the charge.  The END_RAPID.com script 
available here:
http://bl831.als.lbl.gov/END/RAPID/end.rapid/Documentation/documentation.htm
can be useful for doing several parallel occupancy refinements with the 
benefit of also adding noise to the data to get a more realistic error bar.

HTH

-James Holton
MAD Scientist


On 8/28/2014 7:49 AM, Alejandro Virrueta wrote:
> Hello,
>
> I am new to crystallography refinement, and I have a question (I'm 
> sorry in advance if it is a stupid one):
>
> Is it possible to extract all the density values (observed and 
> model-computed) from an mtz file? I need this information in order to 
> quantify the volumes of the difference regions (peaks and holes).
>
> Thanks,
> Alex