Diff for "EMAN2/Eman2Metadata"

Differences between revisions 4 and 19 (spanning 15 versions)

Parameters/Metadata stored in EMData Objects

The EMData object, and its representation on disk in the BDB local database, XML files, and when serialized in Python using 'pickle', supports the concept of arbitrary header parameters also known as metadata. This metadata are key/value pairs. The keys are always simple ascii text, and the values may be virtually anything represented as an EMObject, including simple ints, floats and strings, as well as more complicated objects such as Transform classes. If an EMData object is stored in some fashion other than the 3 mechanisms above, some loss of metadata is almost guaranteed. The file i/o objects will try to preserve some of the basic metadata, but most of the cryoEM formats simply don't support arbitrary header-data. The EMAN2 convention is to use BDB for most internal purposes, and to use HDF5 for data transfer/exchange.

This page will serve as a repository for the officially supported parameter key/value pairs. While you are free to set any metadata keys/values you like in an EMData object, the names listed here may be interpreted in specific ways by specific modules within EMAN, so it would be unwise to abuse them. Also, if you make up your own name for some purpose, it wouldn't hurt to register it here in the 'unofficial' section, to avoid it being used by someone else for a different purpose.

Special tags (read-only for getting image info)

These values are cached and only recomputed if the image changes

nx,ny,nz	int	Dimensions of the image, also available as get_xsize(),etc.
minimum	float	Smallest value in the image
maximum	float	Largest value in the image
mean	float	The average pixel value in the image
sigma	float	The standard deviation of the pixel values in the image
square_sum	float	Sum of the squares of the pixel values
mean_nonzero	float	The mean value of all nonzero pixels
sigma_nonzero	float	The standard deviation of the pixels ignoring pixels which are zero
is_complex	int	Flag indicating that the image is complex (R/I or A/P pairs)
is_complex_ri	int	Flag indicating that a complex image is R/I not A/P
changecount	int	An integer which is incremented every time the image is marked as changed
data_path	string	Used only in BDB files, to indicate that the binary data for an image should be read from an alternate location. Data cannot be written back to such objects.

These values are computed on the fly

skewness	float	Skewness of the pixel values
kurtosis	float	Kurtosis of the pixel values
median	float	Median value of the pixel values
nonzero_median	float	Median value of nonzero pixels

Official tags (used in EMAN2/SPARX as distributed):

apix_x,y,z	float	Angstroms per pixel on the x-axis (also _y and _z). If _y or _z are 0 or not present it will be assumed that they are the same as _x. Note that CTF objects have an independent value for A/pix
xform.projection	Transform	A Transform object used by Projectors. It is applied to a 3-D model prior to projecting by summing along Z. The inverse of this Transform is used by Reconstructors
xform.align2d	Transform	A Transform object representing a 2-D transformation used to align this EMData object to a reference in 2-D
xform.align3d	Transform	A Transform object representing a 3-D transformation used to align this (3-D) EMData object to a (3-D) reference
ptcl_repr	int(float?)	If an image represents the average of one or more other images, this is the count of the number of particles that went into the average
class_id	int	Set by classification routines to indicate which class number the particle is in
eigval	float	Eigenvalue, only set for images which represent Eigenvectors
render_min,max	float	Used when rendering an image to 8/16 bit integers. These are the values representing the minimum and maximum integer values
ctf	Ctf subclass	A subclass of Ctf containing all CTF parameters
ctf_phase_flipped	bool	Set to 1 if the CTF phases have been flipped
ptcl_source_coord	tuple	The central coordinate of a boxed particle in terms of its source image
ptcl_source_image	string	The name of the image from which the particle was extracted. Full path, may be in bdb syntax

Proposed new Official tags (comments welcome):

apix_scan	float	Scan pixel size in Angstroms	(there are already parameters for apix_x/y/z above. Is this different in some way ?, you could provide this as supplementary information, but apix_x/y/z remain the 'official' values. Is this what you want ?)
box_location	int_array	4 values, x0, y0, xsize, ysize representing the location of the particle in the original (box_source) image	(Pawel suggested this be changed to the reduced image, because normally we first reduce the micrograph, the window it.) (No, the box location should be in the coordinates of the referenced 'parent' image. If you want to reference a reduced image you can, but I think it makes a lot more sense to provide the capability of refining the coordinates from the reduced image when you return to the original image.) Pawel: the coordinates in boxer refer to the image from windowing was done. This is is (or can be) a reduced micrograph. There is more confusion here: name apix_scan suggests this is pixel size of the scan, NOT THE REDUCED MICROGRAPH FROM WHICH PARTICLES WERE WINDOWED. Incidentally, both pixel sizes are needed and have to be in the header. Steve: This differs from the philosophy of e2boxer, which is that you always provide e2boxer with the original image, it may internally downscale it for boxing, but the final box positions are in terms of the original image. I don't understand why you would want to externally downscale, then have to rescale the coordinates again later ? This is very messy. Anyway, any single image has a particluar A/pix value associated with it. I have no objections to something like apix_original, but what exactly is the point ? You aren't likely to rescale reduced images back to their original size...
box_score	float	A value representing the relative quality (meaning may vary) of this particle compared to others
box_source	string	Filename (not full path) of the image this particle was extracted from
box_source_id	string	Other (database) identifier of the image the raw data came from if available

Unofficial tags (To prevent reuse, used by someone in their own code or for testing):

match_n	int	used to represent the number of a reference particle this particle best matched
match_qual	float	used to represent the quality associated with match_n, smaller is a better match

-  ⇤ ← Revision 4 as of 2008-10-02 06:21:03 → 
  Size: 4493
  Editor: SteveLudtke
  Comment:
+   ← Revision 19 as of 2009-05-28 15:39:34 → ⇥
  Size: 6818
  Editor: SteveLudtke
  Comment:
-Deletions are marked like this.
+Additions are marked like this.
 Line 19:
+||data_path||string||Used only in BDB files, to indicate that the binary data for an image should be read from an alternate location. Data cannot be written back to such objects.||
 Line 28:
-||apix_x,y,z||float||Angstroms per pixel on the x-axis (also _y and _z)||
+||apix_x,y,z||float||Angstroms per pixel on the x-axis (also _y and _z). If _y or _z are 0 or not present it will be assumed that they are the same as _x. Note that CTF objects have an independent value for A/pix||
 Line 36:
+||ctf||Ctf subclass||A subclass of Ctf containing all CTF parameters||
||ctf_phase_flipped||bool||Set to 1 if the CTF phases have been flipped||
||ptcl_source_coord||tuple||The central coordinate of a boxed particle in terms of its source image||
||ptcl_source_image||string||The name of the image from which the particle was extracted. Full path, may be in bdb syntax||
-Line 39:
+Line 42:
-||box_location||intarray||4 values, x0,y0,xsize,ysize representing the location of the particle in the original (box_source) image||
+||apix_scan||float||Scan pixel size in Angstroms||(there are already parameters for apix_x/y/z above. Is this different in some way ?, you could provide this as supplementary information, but apix_x/y/z remain the 'official' values. Is this what you want ?)||
||box_location||int_array||4 values, x0, y0, xsize, ysize representing the location of the particle in the original (box_source) image|| (Pawel suggested this be changed to the reduced image, because normally we first reduce the micrograph, the window it.)     (No, the box location should be in the coordinates of the referenced 'parent' image. If you want to reference a reduced image you can, but I think it makes a lot more sense to provide the capability of refining the coordinates from the reduced image when you return to the original image.) Pawel: the coordinates in boxer refer to the image from windowing was done.  This is is (or can be) a reduced micrograph. There is more confusion here: name apix_scan suggests this is pixel size of the scan, NOT THE REDUCED MICROGRAPH FROM WHICH PARTICLES WERE WINDOWED. Incidentally, both pixel sizes are needed and have to be in the header. Steve: This differs from the philosophy of e2boxer, which is that you always provide e2boxer with the original image, it may internally downscale it for boxing, but the final box positions are in terms of the original image. I don't understand why you would want to externally downscale, then have to rescale the coordinates again later ? This is very messy.  Anyway, any single image has a particluar A/pix value associated with it. I have no objections to something like apix_original, but what exactly is the point ? You aren't likely to rescale reduced images back to their original size...||
-Line 43:
+Line 47:
-||microscope_voltage||float||Microscope voltage in kV||
||microscope_cs||float||Cs of microscope in mm||
||ctf_defocus||float||Defocus in microns, underfocus positive||
-Line 49:
+Line 50:
+||match_n||int||used to represent the number of a reference particle this particle best matched||
||match_qual||float||used to represent the quality associated with match_n, smaller is a better match||
-Line 50:
+Line 53:
-|| || ||
|| || ||