Currently only has fast_autofocus, and there
may be some work to do on timing, but it works :)
Getting timestamps from the camera rather than
time.time() would be ideal, but it would take some thought to tie that up with
the encoder.
I'm using a low-res stream, as it seems impossible to
turn the bitrate control of the MJPEG stream off,
at least within the picamera2 API.
I've refactored the CI substantially, using the
new `extends` keyword to tidy it up a lot.
I have also changed from running the Python
tests on Python:3.7 to using a Raspberry Pi
OS from the Balena project.
This means we are now ONLY locking
dependencies for the Pi, and we are no longer
expecting the Pipfile to work on non-arm
systems.
Including both piwheels and pypi in Pipfile caused hash mismatches,
which caused installation to fail. I've removed pypi, but this may
break installation on other platforms.
I may need to duplicate Pipfile and Pipfile.lock, one for Pi and
one for non-Pi platforms.
I can confim this commit installed successfully on a Pi.
I couldn't install this on a Pi, because it incorrectly chose
versions of e.g. numpy that did not exist in binary form for the
pi. I re-locked dependencies with:
`PIP_ONLY_BINARY=":all:" pipenv lock --dev`
This forced the use of wheels, and not only completed but did so
in ~10 minutes.
OpenAPI validation seems to have become stricter about checking for None defaults
in parameters that don't allow None. I have
modified two things as a result:
1. StageTypeProperty (used to pick between SangaStage and SangaDeltaStage)
now defaults to SangaStage (which is the
original behaviour anyway)
2. It is now allowed to pass x,y,z=None when making a move - this is the same as
not passing the respective argument, so the
function already correctly handled this case.
The `thing-context` definition used a 2019 draft of how to specify a
tuple (where `items` set the mandatory items and `additionalItems`
set the rest). These have been renamed to `prefixItems` and `items`
respectively, and I have applied this change. Schema now validates
again :)
A side effect of re-locking dependencies is having a newer marshmallow.
This deprecates having `description=` as a keyword, and puts it in a
separate metadata arg instead.
This commit is the start of my search-and-replaceing to update to the new
format.
The update to pylint means we were failing because open()
doesn't specify the encoding everywhere. I have now specified utf-8
everywhere. This was patchy before, and is default behaviour on the
Pi. There's a slim chance it will cause some issues on Windows, but
that shouldn't affect anyone outside the developers.
I've also ignored a couple of new spurious warnings, and explicitly
ignored some unused variables.
Dependencies could use some revision - in particular could we use
Flask 2? That's a LabThings issue really...
I have updated a few dependencies (mostly dev ones), as ever Black is
an issue - have reverted to the previous pinned prerelease because the
full release is incompatible with flask 2.
I have:
* Moved the autofocus and focus-prediction code into a
new `FocusManager` class. This hopefully keeps the logic relating to
axial motion in one place.
* Moved set-up code relating to autofocus and background detection
into separate functions.
* Changed the scan path from a ragged list-of-lists to a one dimensional
list. I've left the old 2D function and added a new 1D function that
calls it and coverts, so it's not a breaking change.
The actual sequence of moves executed, and the accompanying logic, is
unchanged from the previous commit. I've tested this a couple of times,
on my microscope with actual hardware.
I don't think it's necessary to test more widely as this is only a
refactoring change, not an algorithm change.
The shift from 2D to 1D scan path was one I initially decided against,
because I was trying to keep the new code as small as possible, and
avoid refactoring what's already there. Since I'm doing that anyway,
I have taken the opportunity to eliminate the concept of scan
"lines".
The old behaviour was to always use the position of the last point
as the starting point for the next autofocus. There was an exception
to this for raster scans, where the big jump used the first point
of the last line instead. The new behaviour always uses the closest
point, which reproduces this behaviour without the need for a hard
coded exception.
If the "fast" scan axis (y) has a longer step size than the "slow"
scan axis (x), we may base the autofocus off the previous row, rather
than the previous point in the current row. I don't see that this
should be any less reliable than the current behaviour, and is
arguably better. It's also unlikely to be noticed, because our
default scan settings have longer spacing in X. I think the
reduced complexity of the code is definitely worth the small
chance of changing some edge-case behaviour.
There is now a button that appears when the background-detect
extension is installed, allowing you to skip autofocus if the
field looks like background.
The primary change here is that there's now an option
to skip autofocus if the background detect plugin says
the current image is background.
I have also overhauled the way it picks the next Z position
based on Joe's code; instead of just using the last point, it will
pick the closest point where we have a successful autofocus
recorded. This will usually be the last point, except for raster
scans where it neatly reproduces the behaviour of the old code
but without needing to treat it as a special case (when we jump
back to the start of a line, it will use the z position of the start
of the previous line, rather than the end of the previous line).
This does represent a minor change to previous behaviour, but
it should not break anything that isn't already broken, i.e. it might
cause slightly odd behaviour if autofocus gives random results -
but probably indistinguishable from the current behaviour.
