I've swapped out various `logging.exception` calls for
`logging.error` with `exc_info` set to the exception.
My reading of the docs is that the two shoulld be equivalent,
but the former fails with an error related to
message formatting, as if there was an extra (or missing) '%'.
I've changed the format of the downloaded zip file, so that it
now puts the stitched images at the top level (if they exist).
I've also modified the time of the last stitched image so it
returns None if it doesn't exist - this avoids HTTP errors in
the client.
There's now an action that will save all settings to disk.
This copies code from `labthings_fastapi.thing_server` so
may want to be deduplicated in the fullness of time.
Removed an unnecessary `Optional` and removed the `scan_` prefix from scans that have a non-empty name.
I also added a closing ` to a logging statement.
UUIDs don't serialise to JSON, so I'm now saving it as a plain
string and reconstructing a UUID object when it's returned.
Returning a UUID seems clearer than returning a string.
I now define the variables needed in the finally: block at
the very start, so I can test if they are None.
I've reordered the final move so it can happen as we are awaiting the background processes. I've added exception handling so this won't cause problems with the lock.
We've removed the initial double-autofocus (we just do a
single looping autofocus at the start), and now only do 3 retries rather than 5 if the focus is rejected.
Stitching is now done automatically in a sub process by the
server. This is much cleaner - and all we need to do is poll for
file updates.
I've also styled the log display slightly better.
I'm now running stitching in subprocesses during the scan.
This seems to be working well - I'm using multiple CPU
cores and getting images out. However, the only way to
avoid circular dependencies was to combine the Things.
I'm still getting not-infrequent memory allocation errors from the camera, which may or may not be related.
To save some CPU cycles, we will return immediately if the
images don't look newer than the stitch. NB this does mean
that the stitched image will be repeatedly transferred, as its
URL will change each time it's re-requested.
Alternatively, we could fail with an error, which may be more efficient, at the expense of being uglier.
checkExistingTasks was looking up the task's `self` link by
checking for `rel=self`, which failed. I have corrected this
to `rel="self"` - `self` would have evaluated to `undefined`.
The log viewer was scrolling to the bottom when new logs
appeared, but not when the status updated. This meant that the status update may have been invisible. I now scroll
when the status changes too, which should fix the problem.
