# Difference between revisions of "Volume center"

(One intermediate revision by the same user not shown) | |||

Line 46: | Line 46: | ||

Note: When computing the [[Fourier Shell Correlation]] of two volumes, the central pixel is left aside from the computation, as this ''shell'' would only contain one component, and the FSC component relative to this shell will always be 1. | Note: When computing the [[Fourier Shell Correlation]] of two volumes, the central pixel is left aside from the computation, as this ''shell'' would only contain one component, and the FSC component relative to this shell will always be 1. | ||

+ | |||

+ | == During particle cropping== | ||

+ | |||

+ | Particles are never interpolated when extracted from a volume, i.e., a file that represents a particle extracted from a tomogram will contain on each voxel the same intensity value that the analogous voxel had in the tomogram. If the center of a particle indicated by the table used for cropping is not the center of a voxel (i.e., not a semiinteger value), the difference between the coordinate in the table and the center of the voxel will be added in the columns 4:6 (the ''shift'' columns) in the output table ''crop.tbl''. In this crop.tbl, the columns 24:26 will always have semiinteger values (i.e., centers of voxels) |

## Latest revision as of 10:01, 5 March 2018

The center of a discretized volume can be defined in different ways. *Dynamo* uses the same convention in all its functions. For the formulas in this page, remember also that *Dynamo* uses the convention of counting pixels with the index 1, (not 0). The pixel "on the corner" with the first coordinates in a volume `V` is thus denoted as `V[1,1,1]`.

## Contents

## Pixels and continuous coordinates

Sometimes it is necessary to clearly distinguish between (discrete) pixel indices and (continuous) point coordinates.

We use the notation `[i,j,k]` for pixel indices, and the notation *(x,y,z)* for continuous coordinates (or simply *coordinates*). The origin of coordinates in a volume is the *corner* of the first pixel `[1,1,1]`. This way, the coordinate *(N,N,N)* is located exactly in the corner oposite to the origin of coordinates.

## Direct space

For a volume of `V` NxNxN pixels, *Dynamo* considers by convention the pixel located at ` [N/2+1,N/2+1,N/2+1]` as the central pixel of `V`.

### Rotation

Rotation needs defining on a concrete *point*, not on a pixel (as a pixel is actually a square with an area). The convention in *Dynamo* is to define the rotation center point in the middle of the center pixel, thus at the continuous coordinate *(N/2+1/2,N/2+1/2,N/2+1/2)*.

This might seem inelegant, as the geometrical center of the volume is clearly located at the position *(N/2,N/2,N/2)*, (which is located in a corner shared by eight pixels). However, *Dynamo* skips to the *(N/2+1/2,N/2+1/2,N/2+1/2)* convention, as it keeps coherency with the definition of center in Fourier space (where it is important that the coordinate center falls in the middle of a fourier pixel), and it is also a convention widely used in EM software packages.

### Placing templates in a volume

Sometimes you need to place a template `T` inside a bigger volume `V`, by passing a pixel coordinate `r` inside the bigger volume. In such cases the placement follows by setting the central pixel [N/2+1,N/2+1,N/2+1] at the pixel position `r` in `V`, i.e.:

`
V[x-N/2 : x+N/2-1 , y-N/2 : y+N/2-1, z-N/2 : z+N/2-1] = T[:,:,:];
`

### While particle cropping

By convention, the table contains in the positions 24:26 the coordinates where the cropping will act. If those positions are not the exact center of a pixel, the cropped volume will be centered in at the closest pixel center. The distance between the actual position in the table and the actual ( semiinteger) position used by `dtcrop` will be reflected in the output table `crop.tbl`.
In this modified table, 24:26 should represent coordinates that represent exact centers of pixels, and columns 4:6 should have the shifts of the original table plus the difference in columns 24:26 between the original and the processed table.

#### Cropping positions of particle centers

The *cropping positions* will appear in the `crop.tbl` in columns 24:26, being of type i+0.5, j+0.5, k+0.5 for i,j,k integers. A particle cropped at the coordinate (i+0.5, j+0.5,k+5) will have at its center pixel (after cropping) the intensity of the pixel [i+1,j+1,k+1].

#### Actual positions of particle centers

The *actual* subpixel coordinates of the particles in the `crop.tbl` can be computed as the sum of the columns 4:6 (shifts) and crop coordinates (cols 24:26) in the crop.tbl. Note that this addition will be the same for the original table that is fed into `dtcrop`

## Fourier space

When we depict a power spectrum, the center pixel ` [N/2+1,N/2+1,N/2+1]` corresponds to the zero-th Fourier order. The magnitude of this pixel does not represent an oscillation, but just the average intensity of the volume in the current space. Luckily, this is a convention used in many EM packages an also in Matlab.

Note that this implies that the Fourier pixels conveying the Nyquist frequency in a direction are NOT to be found at the most positive indices of the Fourier volume. For instance, you might expect the Nyquist frequency for waves in the x direction to be conveyed in the pixel `[N,N/2+1,N/2+1]`. That's wrong: this pixel is located at a distance (measured between pixel centers) of N/2-1 pixels. The actual Nyquist frequency corresponds to pixel `[0,N/2+1,N/2+1]`, which is at the correct distance. Remember, the theory of Discrete Fourier Transform on *real* volumes (as density maps are) tells us that all components of the power spectrum are center symmetric.... other than the Nyquist component, that appears only one for each direction (thus no redundancy)

Note: When computing the Fourier Shell Correlation of two volumes, the central pixel is left aside from the computation, as this *shell* would only contain one component, and the FSC component relative to this shell will always be 1.

## During particle cropping

Particles are never interpolated when extracted from a volume, i.e., a file that represents a particle extracted from a tomogram will contain on each voxel the same intensity value that the analogous voxel had in the tomogram. If the center of a particle indicated by the table used for cropping is not the center of a voxel (i.e., not a semiinteger value), the difference between the coordinate in the table and the center of the voxel will be added in the columns 4:6 (the *shift* columns) in the output table *crop.tbl*. In this crop.tbl, the columns 24:26 will always have semiinteger values (i.e., centers of voxels)