[3dem] MRC format

michael michael at ImageScience.de
Fri Aug 23 08:26:23 PDT 2013


Dear all,

Sorry for once more coming up with this issue. But when I was re-reading 
the MRC related mails today I recognized that there is an inconsistency 
in the definitions of 3D volume stacks.

Roberto Marabini wrote:
> Starting in version 3.1  we use the following convention:  For 3D
> maps of single particles ISPG=1 and NSYMBT=0. For 2D image/stack
> ISPG=0 and NSYMBT=0. . In case ISPG=401 the data is read as a stack of
> volumes, being the mz field in header the number of volumes in the
> stack. Finally, MZ=1 for 2D stacks and MZ=NZ for single volumes.

Anchi Cheng wrote:
> single image:  ISPG=0 NZ = MZ = 1
> image stack: ISPG=0 NZ = N object
> single volume: ISPG=1 NZ = MZ = Z slices
> volume stack: ISPG=401 MZ = Z slices; NZ / MZ = N object

If I understand these mails correctly both definition are not the same:

    Table 1: www.ImageScience.de/patches/MRC_Problems.png (a link only 
because the 3DEM mailing does not accept large pictures)

The problems is how one defines NZ. In the case of a 3D stack XMIPP 
(Roberto) uses NZ as the number of sections OF EACH volume whereas 
SCRIPPS (Anchi Cheng) is using NZ as number of ALL sections in the file 
(like it is done for a stack of 2D images).

NZ is defined as "number" of sections" but for a stack of 2D images it 
is also used as "number of all images". So I think for a 3D stack we 
should also use NZ = number of all images/sections (the SCRIPPS approach).

MZ is defined as "number of intervals along Z". May be I am wrong but I 
would translate this into our "3DEM language" as number of objects (the 
XMIPP approach).

So I think the best definition is a mixture of the SCRIPPS and the XMIPP 
approach (changes in red):

    Table 2: www.ImageScience.de/patches/MRC_Suggestions.png (a link 
like before)

And if one also likes the idea of interpreting MZ as number of objects:

    Table 3: www.ImageScience.de/patches/MRC_Problems.png (a link only 
because the 3DEM mailing does not accept large pictures)

I think this is a consistent definition. But I do not know if any MRC / 
CCP4 / IMOD program accepts any of our definitions ;-) . Probably 
Richard and/or Jude can immediately answer this last question.

Regards and have a nice weekend
Michael


-- 

======================

Michael Schatz
Image Science Software GmbH

Gillweg 3
D - 14193 Berlin
Germany

Besuchereingang / Entrance:
Hubertusallee

Tel: +49 30 8909 5326
Fax: +49 30 8909 5321
URL: www. ImageScience .de

Geschäftsführer/Managing Director
Michael Schatz

HRB: 33106 Berlin-Charlottenburg
VAT/USt-Id-Nr. DE 136613484

======================


-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://mail.ncmir.ucsd.edu/mailman/private/3dem/attachments/20130823/586547c7/attachment-0001.html


More information about the 3dem mailing list