We have been very very busy since the last v3 alpha release around Christmas time. This release has been a huge amount of work and brings us significantly closer to a semi-stable beta release. We really hope that the next release will be stable enough to be a beta (hopefully including a return of the Gallery, Extensions, and direct control from the microscope).
For now, anyone who wants to can try the v3.0.0-alpha5.
Using the pre-release
To install the pre-release on a microscope:
Using Raspberry Pi Imager 2
Select App Options → Edit Content repository
Select Use custom URL and paste in https://build.openflexure.org/raspbian-openflexure/manifest.json
Click Apply and Restart
Then select Raspberry Pi 4 → OpenFlexure Raspbian v3 Pre-Release → OpenFlexure Raspbian v3.0.0-alpha5
OR download the image directly and install with Raspberry Pi Imager 1.x (Imager 2 will not allow customisation with a directly downloaded image)
What has changed.
Some highlights of the new release are:
OS changes:
OS Now supports Raspberry Pi Imager 2
Smaller SD card image size (by cutting down on installed packages that were not needed)
Server changes:
Created ScanWorkflows, a backend change that allows switching scan methods. Enabling new types of scanning:
Raster Scan
Snake Scan
CChip Scan (experimental, requires a configuration change to use)
Transition frontend from the end of life Vue2 to Vue3 which is in active development!
Improvements to the simulation microscope including more simulation samples and camera options. Speeding up development.
“Jogging” movement. The microscope can now move continuously when an arrow key is held.
Improved server side UI specification. This brings us closer to “Things” being able to define their own tab, which will soon enable plugins in v3.
A user interface for recentring and range of motion.
Improved fallback server interface.
Backlash correction in scanning.
OpenCV camera switching. Enabling changing between cameras in settings when using the manual configuration.
A huge number of other bug fixes and improvements.
Stitching changes:
Better error handling and checking whether settings can successfully stitch
Add support for masking the correlations between pairs of images, depending on your stage performance
Add metadata to exported JPEG to show information about the scan
“Behind the scenes” changes that will improve development
Move from LabThings Dependencies to ThingSlots. This has allowed for:
Much easier communication between Things
Static type checking
Simpler action creation.
Improved testing, including better defined testing environments, separation of integration and unit tests, and tests passing on Windows
Updated how stitching logs to make sure nothing is buffered or delayed
Improved plotting of correlations and thresholds in stitching, for setting manual cut offs
Move correlation code into stitching rather than importing, to allow greater control and less external dependence
Move the OFM CLI tools into the server repo.
Final word
It has been a huge release, including some big changes upstream in LabThings. There has been a lot of work from the core team (Me, Joe, Beth, William, and Richard) with a lot of help from Ben (@chish). Also thanks to Antonio (@kny5) for migrating the user interface from Vue2 to Vue3, this will make it much easier to maintain and keep modern and secure.
I should also thank NLNet whose funding enabled much of Antionio and my work on this release and previous releases! We were funded through NGI0 Commons Fund, a fund established by NLnet with financial support from the European Commission’s Next Generation Internet program. Learn more at the NLnet project page.
Trying this version on HQ cam. Had to move the condenser very high up, otherwise the entire FOV was yellow. The edges are visible on the HQ and yellow’ish. Running a scan now and I’ll see what happens when it finishes.
Seeing some stability issues with the HQ camera setup, namely with the stream of the camera itself. Had this happen to the live stitch, with a similar thing happening (loss of stream) to the preview from the camera when jogging earlier.
Yeah, the HQ should probably be rebased against a HQ focussed dev branch. I think @JohemianKnapsody can help with that.
We are hoping that the next release will also include some camera API consolidation, enabling us to decouple the cameras in a way that makes them both first class citizens. There are a few other core focusses so I won’t promise more of a timeline than a promise that it is very important to us and it will be very soon.
Okay, I managed to get the camera calibration to work. I moved the slide over the white paper on the side of the slide and it didn’t go yellow. Had to drop the exposure a bit, but getting a good result. Now the issue is that I cannot get the stage calibration to work no matter which sample I use. I changed back to alpha4 and that didn’t work either. I’ll see if I can mess around with the code to get it to work.
A bit of a development update from our side. There has been a fair bit of progress since this alpha was releases:
We have some test images working with a full os image rather than just a lite one (needs more testing)
We have improved our camera API which means that HQ should now work “out of the box” after one configuration file change
We have added a management server on port 5001, this can be used to restart the microscope server (eventually will allow updating the config, and doing updates, installing extensions, etc)
We are working towards a (very basic) reimplementation of the gallery.
There are a number of things we still need to do before we are ready to release beta1 (such as creating a new extension framework) Anyone who wants to follow along with this progress can see the burndown chart for the beta1 milestone here:
While we would like to move from alpha 5 straight to beta 1, we also see that beta1 really needs a bit more time to be ready. We are considering whether we should continue fully a pace for the beta 1 release of pause soon and release alpha 6 for some feedback.
I feel like going for alpha6 would be the better choice, smaller list of changes to look at, lower chance of a “show stopper” or an implementation that could be hard to “go back” from.
What ever consideration that will make for the best beta1 (if that thought is of any help ). If an alpha 6 is out I’ll be happy to give it a go for the Gallery, though I doubt I’ll come up with any useful feedback.
Thanks for sharing the chart too, really nice things ahead!
). If an alpha 6 is out I’ll be happy to give it a go for the Gallery, though I doubt I’ll come up with any useful feedback.