I've now defined parent classes for camera and stage, and depend only on those. This allows
proper typing while enabling the actual hardware
classes to be swapped.
The interfaces definitely aren't final - this is a first
draft, largely to enable me to test out the concept
of a configuration server.
This allows the server to run on a laptop, to some extent. I've not tested if this will make the whole
web app work properly.
As StreamingPiCamera2 is hardcoded in various places, this certainly doesn't make cameras totally
interchangeable - but it is a step towards that.
I changed the labthings package such that it will
only install the client dependencies by default.
This is now fixed by requiring the [server] extras.
In the future we might split labthings into client
and server packages.
The calibration modal was not starting properly, because
the component was not mounted when its show method
was called. Calling it from the `mounted` method solves
the problem and we don't get the error.
I'm not 100% sure this was introduced by refactoring the
taskSubmitter, though it's possible. However, I think the
fix is uncontroversial and it should probably have been there
all along.
I removed some defunct properties - this introduced a couple
of problems, which are resolved by:
* no longer checking for fastAutofocusUri
* removing the unused prop availablePlugins from the calibration modal
I've changed tasksubmitter to accept a "thing" and "action" rather than a single URL. This seems more in keeping with
propertyControl, and eliminates the need for loads of
computed properties.
I've also deleted (rather than just commenting out) chunks of the web app that are no longer in use. These may be
reinstated in the future - but we can get them from git
history. It's less confusing not to have vestigial
code in the repo.
This builds OK but is not, as yet, tested with hardware.
If any pixels in the manually processed raw image end up
saturated (>255), this causes an error. I've now manually
clamped the values between 0 and 255 to fix this.
It would probably be a good idea to warn when this happens,
as it does mean we're losing data.
I've replicated more of the camera pipeline in the images
saved during scans - in particular, I've added the colour
correction matrix (increases saturation) and the contrast
agorithm (implements gamma correction).
This slows down saving to ~0.5-2 seconds, but that's still less time than it takes to move.
