Age | Commit message (Collapse) | Author |
|
|
|
|
|
See 4fbe2e349908a53032b3f23c2180a46e4f770c92.
|
|
|
|
|
|
|
|
|
|
The old way could potentially read beyond the bounds of the array.
|
|
It's confusing and unnecessary.
|
|
|
|
|
|
'buf' has to be char *, otherwise "buf+len" isn't portable.
'len_read' has to be int, because that's the return type of gzread. If
the value is immediately put into a size_t, the sign information is lost
and we can no longer tell if gzread() failed.
|
|
These local variables were being assigned just before returning.
|
|
|
|
|
|
'changed' is initialised to zero, so there's no way this check can fail.
|
|
|
|
|
|
|
|
|
|
|
|
On some systems, this conflicts with DST_NONE in sys/time.h.
|
|
|
|
Just like the individual indexing methods, these aren't part of the API.
peakfinder8.h was there twice, for some reason.
|
|
|
|
Making them opaque seemed like a nice idea, because all the indexers
could take care of their own command-line arguments. However, it
doesn't work at all when indexing is run via the API.
|
|
Rationale: Although the format has technically changed, CrystFEL 0.9.1
and older do not read the "hdf5/" lines anyway. The new "header" lines
are just noise, as far as they are concerned. However, increasing the
version number causes older CrystFEL versions to reject streams written
by newer CrystFEL versions. This is inconvenient, but will be a
particular problem since CrystFEL 0.10.0 will most likely be released
without a working "geoptimiser". We therefore need to be able to use
older CrystFEL versions for refining geometry. Older versions are
perfectly capable of reading newer streams.
In general, the semantics of stream version numbers are a bit messed up,
and we need to work out what they really mean.
This reverts commit fdce01adf9fc5950904b644ea755760cb32ec5b2.
|
|
The format for storing headers has changed from hdf5/location to
header/type/location.
|
|
The old way of recording metadata in the stream unfortunately doesn't
include any information about the data type. Most of the time, floating
point is what's intended. Older CrystFEL doesn't know about integer
headers at all, but there might be string values if --copy-hdf5-field
was used.
By interpreting "hdf5/something = val" as floating-point, most things
will work, e.g. camera length from HDF5 header enabling stream to be
loaded without access to the image data. Anything that can't be
interpreted as floating-point will be noisily ignored when loading the
stream.
|
|
|
|
|
|
|
|
|
|
Closes: https://gitlab.desy.de/thomas.white/crystfel/-/issues/36
|
|
|
|
|
|
|
|
Big improvement on just sending NAN back.
Fixes: https://gitlab.desy.de/thomas.white/crystfel/-/issues/37
|
|
Prompted by the article linked below, for each FIXME/TODO I've either
referenced an issue in the tracker, or removed it if it's not worth
fixing.
https://schleiss.io/plotting-source-code-todos-for-open-source-projects
|
|
This removes some old stub code. There doesn't seem to be a big need
for doing what the FIXME suggests.
|
|
|
|
|
|
|
|
|
|
This clears up multiple layering violations which were starting to get
in the way. It enables "string" headers to be stored directly, and it
will make it much simpler to add new header types in the future.
Along the way, this changes all the floating point header stuff to use
double precision. This is needed for EuXFEL event IDs.
Closes: https://gitlab.desy.de/thomas.white/crystfel/-/issues/34
|
|
convert_int was using strtod. Whoops!
|
|
|
|
When there is only one panel, we can safely assume that fs/ss bad
regions refer to it without it being stated in the geometry file.
This allows some older Pilatus geometry files to be used without
complaints.
A further improvement would be to determine the panel when all the data
comes from one "slab" so the panel is still ambiguous. However, on
further thought it seems like a lot of work to do this reliably in all
cases. I'm not even sure that this case in particular is causing anyone
problems.
Closes: https://gitlab.desy.de/thomas.white/crystfel/-/issues/32
|
|
|
|
|