1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
|
CrystFEL detector geometry files
--------------------------------
The detector geometry is taken from a text file rather than hardcoded into the
program. Programs which care about the geometry (particularly indexamajig,
pattern_sim and powder_plot) take an argument "--geometry=<file>"
(or "-g <file>"), where <file> contains the geometry.
A flexible (and pedantic) representation of the detector has been developed to
avoid all possible sources of ambiguity. CrystFEL's representation of a
detector is broken down into one or more "panels", each of which has its own
camera length, geometry, resolution and so on. Each panel fits into the overall
image taken from the HDF5 file, defined by minimum and maximum coordinates in
the "fast scan" and "slow scan" directions. "Fast scan" refers to the direction
whose coordinate changes most quickly as the bytes in the HDF5 file are moved
through. The coordinates are specified inclusively, meaning that a minimum of 0
and a maximum of 9 results in a width of ten pixels. Counting begins from zero.
All pixels in the image must be assigned to a panel - gaps are not permitted.
In the current version, panels are assumed to be perpendicular to the incident
beam and to have their edges parallel. Within these limitations, any geometry
can be constructed.
The job of the geometry file is to establish a relationship between the array
of pixel values in the HDF5 file, defined in terms only of the "fast scan" and
"slow scan" directions, and the laboratory coordinate system defined as follows:
+z is the beam direction, and points along the beam (i.e. away from the source)
+y points towards the zenith (ceiling).
+x completes the right-handed coordinate system.
Naively speaking, this means that CrystFEL at the images from the "into the
beam" perspective, but please avoid thinking of things in this way. It's much
better to consider the precise way in which the coordinates are mapped.
The syntax for a simple geometry might include several entires of the following
form:
; Lines beginning with a semicolon are ignored.
; The number of panels must be specified first
n_panels = 64
; The number before the slash indicates which panel is referred to.
; The range of pixels in the HDF5 file which correspond to a panel are given:
0/min_fs = 0
0/min_ss = 0
0/max_fs = 193
0/max_ss = 184
; The readout direction (x, y or 0). If more than three peaks are found in
; the same readout region, they are all discarded. This helps to avoid
; problems due to streaks appearing along the readout direction.
; If the badrow direction is '-', then the culling described above will not
; be performed for this panel.
0/badrow_direction = -
; The resolution (in pixels per metre) for this panel
0/res = 9090.91
; The characteristic peak separation. The peak detection will assume that
; genuine peaks are separated by at least this amount.
0/peak_sep = 6.0
; The camera length (in metres) for this panel
; You can also specify the HDF path to a scalar floating point value containing
; the camera length in millimetres.
0/clen = /LCLS/detectorPosition
; For this panel, the fast and slow scan directions correspond to the given
; directions in the lab coordinate system described above, measured in pixels.
0/fs = +y
0/ss = -x
; The corner of this panel, defined as the first point in the panel to appear in
; the HDF5 file, is now given a position in the lab coordinate system.
0/corner_x = 429.39
0/corner_y = -17.30
; You can suppress indexing for this panel if required, by setting "no_index" to
; "true" or "1".
0/no_index = 0
See the "examples" folder for some examples.
|
