Every EMAN2DB directory will contain an image count cache database which will contain a number of parameters associated with each image in that directory, updated as necessary.

These are metadata parameters associated with a 'Project', like a single particle reconstruction, and may be application specific or global. If an application wishes to make parameters available for other applications to see, it should put them in 'bdb:project' in the local directory and name them as described below. Documentation for application specific parameters not really intended for use by other applications appears here as well. This does NOT document parameters stored in the header of individual images, though we strive to use the same names whereever possible.

Parameters starting with 'global.' are those which could be used equally by any application, other applications wishing to publish parameters for use by others should prefix them with 'appname.'

Dictionary names should begin with the application name, the contents of each dictionary can be freely defined by the application.

«Anchor(e2boxer.cache)» This is the cache associated with e2boxer.py.

Not that by __filename_DD__ it is meant to be a string constructed from the original file name, for instance if the file name was 123458.mrc then __filename_DD__ would be literally “123458_DD”.

* Stored as a string because of some database complication during development

This dictionary stores the most recently used parameters associated with boxing in e2workflow.py

This dictionary stores the most recently used parameters associated with ctf correction in e2workflow.py

This dictionary stores the most recently used parameters associated with initial model generation in e2workflow.py

This dictionary stores the most recently used parameters associated with 3D refinement in e2workflow.py

This dictionary stores the most recently used parameters associated with 2D refinement in e2workflow.py

The raw_directory is used by e2workflow.py for storing imported micrograph/CCD data. The image file tag (e.g. the file tag of /home/somewhere/something.mrc is “something”) may be used to access the image, for example

#!python
a = EMData("bdb:raw_data#something",0)
b = EMData()
b.read_image("bdb:raw_data#something",0)

The short story is e2boxer stores particles in this directory, it uses a naming convention where “_ptcls” is appended to the end of the input image names.

e2ctf stores particles in this directory and appends “_ctf_flip” or “_ctf_wiener”, depending whether the output data are phase flipped or Wiener filtered.

The longer story is - The particles directory is used by e2ctf, e2boxer and e2workflow for storing boxed particle data that has optionally been filtered. In general e2boxer will be the first program that stores data here, and it can be done in a number of ways. People can save directly to the particles directory from e2boxer using the 'write box particle images' button (name may be different) and by making sure the output format is 'bdb'. e2boxer can also be used from the command line for writing output (output format is a command line argument). This is precisely what occurs from the context of e2workflow, which spawns output writing processes using e2boxer.

Note that a naming convention is employed by e2boxer - if the input image names is something.mrc or “bdb:raw_data#something” then the output particles will be written using the filename “something_ptcls”. You can access these images from Python using any of these approaches:

#!python
a = EMData.read_images("bdb:raw_data#something_ptcls",[])
n = EMUtil.get_image_count("bdb:raw_data#something_ptcls")
images = []
for i in range(n):
    images.append(EMData("bdb:raw_data#something_ptcls",i))

e2ctf will also store filtered particle images in the this directory, and these will be either phase flipped or Wiener filtered. Note that the Wiener filtered data are also phase flipped. These particles are stored in the database with “_ctf_flip” and “_ctf_wiener” appended to the input file names, respectively.

The e2boxercache directory has many dedicated particle stacks in it. The currently existing stacks are listed in this table

see also the e2boxer.cache database.