Age | Commit message (Collapse) | Author |
|
The utils file contains two gtk-doc sections, "utils" and "quaternion",
with a change of section halfway through. It seems that gtk-doc doesn't
like it if the declarations are all mixed together.
|
|
This doesn't do much except for preventing a possibly confusing warning
message about "Failed to prepare indexing method none".
You can actually do --indexing=none,asdf, but don't tell anyone...
|
|
Doing so results in one crystal being counted as bad twice, which messes
up the logic which follows.
|
|
You get cbflib/cbf.h if you install CBFlib from source, and cbf/cbf.h if
using the package manager in Fedora, probably other systems as well.
We definitely don't want to include the cbf or cbflib folder in the
include path, because CBFlib may bring its own HDF5 headers, which we
don't want to touch with a bargepole.
|
|
|
|
|
|
|
|
Bad pixel map is not allocated at this point.
|
|
|
|
|
|
|
|
This needed a bit of reorganisation and clarification of who is
repsonsible for loading what. The low-level file loaders, e.g.
hdf5_read and hdf5_read2 in hdf5-file.c or cbf_read in image.c, are
responsible. There is a helper function adjust_centering_for_rail in
detector.h which they can use.
It seems like this could be done more cleanly at the imagefile layer.
However, we need to make sure that the "old" hdfile API still works on
its own, even when not accessed via the new imagefile API.
|
|
|
|
|
|
|
|
Seems to have been added in 2014 and is not used at the moment
|
|
|
|
|
|
|
|
Like zaef, the pixel indices need to be converted to geometrical
coordinates. This increases the indexing rate by about 5% in my test.
|
|
|
|
CrystFEL considers all peak locations to be distances from the corner of
the detector panel, in pixel units, consistent with its description of
detector geometry. In contrast, Cheetah considers the peak locations
to be pixel indices in the data array. Therefore, a half-pixel offset
is needed when importing the peak lists.
For users who need the old behaviour, this commit adds a new option
indexamajig --no-half-pixel-shift to deactivate this offset.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Previously, the indexing system passed all the information on to the
indexing engines and then forgot about it. That made it difficult to do
things like check the indexing solution after prediction refinement,
because the target unit cell was unavailable. Now, the indexing system
itself can keep some information. Of course, that information includes
the private pointers for the indexing engines themselves.
I took the opportunity to streamline things a little bit. The caller
can now set up the indexing system in one step, without having to
separately parse the names of the indexing methods. The caller no
longer has to keep track of a separate array of methods, instead just
one structure which contains everything.
|
|
|
|
The mask paths for all panels have to have the same number of
placeholders, but the masks do not have to have the same number of
placeholders as the panel data blocks.
This also tidies up a few excess strdup() calls, and removes
partial_event_substitution() because retrieve_full_path() can now handle
the number of placeholders being too small.
|
|
|
|
Add F centering
|
|
since asdf always finds primitive cell
|
|
|
|
|
|
|
|
|
|
|
|
The "improved" version of this, added by 9b1374999 along with the new
spot position calculation for out-of-plane panels, actually assumes that
the reflection is at the exact Bragg condition. This is not a valid
assumption here. The difference is small (<0.5 px), but made the
prediction refinement gradients completely wrong.
|
|
|
|
coordinates
We trust the HDF5 peaks, even if we can't see a peak there. That means
we can't reliably take a centroid and "improve" the coordinates. In
some cases, the centroiding procedure seems to be making the peak
coordinates worse than they were originally.
Now, the only remaining checks are:
1. Is the peak in a bad region of the detector?
2. Is it saturated? (but --use-saturated is the default)
3. If --check-hdf5-snr, is it above the minimum SNR?
|