[Imgcif-l] Electron density map parameters

[Joe Krahn <krahn@niehs.nih.gov>]

A few comments on the work-in-progress for density (etc.) maps.

The current spec says:
"The map sampling is being done in the middle of each grid division"

This conflicts with Fourier maps, where values are on grid vertices, 
rather than the pixel/voxel centers. The reason is that Fourier maps 
represent point samples, rather than the integration of a pixel/voxel, 
as it is in the case of most images. Rather than making density maps 
special, maybe there should be a property that distinguishes between 
point samples and integrated divisions. This sort of problem is common 
in graphics rasterization, and imaging/graphics APIs often have 
alternate origin choices.

For grid divisions, maps have one of the following two representations, 
from the examples:
         loop_
          _array_structure_list_axis.axis_id
          _array_structure_list_axis.fract_displacement
          _array_structure_list_axis.fract_displacement_increment
          CELL_A_AXIS 0.01 0.02
          CELL_B_AXIS 0.01 0.02
          CELL_C_AXIS 0.01 0.02


          loop_
          _array_structure_list_axis.axis_id
          _array_structure_list_axis.displacement
          _array_structure_list_axis.displacement_increment
          X 7.5e-8 1.5e-7
          Y 7.5e-8 1.5e-7
          Z 7.5e-8 1.5e-7


Both of these have the problem that the displacement increment can 
produce cumulative rounding errors. It would be better to have a system 
that better allows for an integer number of grid divisions per unit 
cell. Detector images could benefit from this sometimes as well. One 
possibility is to specify a displacement-maximum, instead of an 
increment. Another possibility is to specify the inverse of the 
fract_displacement parameters.

In the case of fract_displacement, is it intended that _axis.vector[*] 
be the unit-cell, rather than a dimensionless unit vector?

Another thing important to electron density maps is symmetry operations, 
which are already defined for structures in category _symmetry_equiv. It 
might be useful to define symmetry with simply matrices/vectors instead. 
Are there any ideas already being considered in this area?

Joe Krahn
_______________________________________________
imgcif-l mailing list
imgcif-l@iucr.org
http://scripts.iucr.org/mailman/listinfo/imgcif-l