We are celebrating the holidays with OpenFlexure Server v3.0.0-alpha 4!
The SD Card image can be downloaded from our build server. Please note that this is an alpha release for testing rather than a stable release.
Weâve made a lot of progress on camera calibration and making scanning more reliable. Background will be closer to pure greyscale than yellow-tinted, and scanning captures more of the edge of samples, so no more cutting off small areas at the edge. Live previews of scans is now a lot faster, and weâve done a lot of work behind the scenes to make our future development faster.
Significant speed improvement for live-preview stitching.
Improved PiCamera tuning and colour reproduction
Algorithm for white-balance calculation improved. Images are grey not yellow.
Improved colour correction matrices
Ship our own custom picamera Tuning files, and improve handling of updating this data
Add contrast and brightness sliders into scan viewer.
Scanning improvements
Capture extra images on the boundary between sample and background to robustly capture the edges of the sample
Add new default background detect method that works on localised image variation not global colour
Add extra checks into smart stack for checking if stack is successful
Stage measuring
Automatic range of motion measurements - Not yet exposed in UI
A new recentre algorithm - Not yet exposed in UI
Improvements to the webapp
Significant modernisation of the webapp build system
UI customises to available Things - This allows different configurations such as manual microscopes with no stage!
Overhaul of the code that runs the Calibration Wizard. This will make it easier to add new calibration steps in future
Add pagination to scan list
Add new âpatch-styleâ microscope configuration file so that the config file doesnât need to be periodically updated during development.
Woo! Slide scanning works for me with the HQ camera now. A bit wonky in places, but still great. Maybe the cat was messing with it when I went to sleep. My suggestion would be the âDownload zipâ button should have a progress bar and a total space the file is going to use. Didnât realize that the file was still downloading after I hit âsaveâ, thought the archive corrupted when it didnât allow me to open
Edit: 10 hours 46 minutes on completely default settings
Edit2: Okay, the resulting file isnât wonky, itâs just the preview
I think yours will need the max-range reduced as there is repetition at the edges.
There are some changes in the pipeline to help with range of motion:
@WilliamW has fixed some issues in hardware that stopped the stage range of motion being square
@chish has created an algorithm for automatically measuring ROM which combined with re-centring should mean we can avoid crashing more reliably. [This algorithm is in alpha4, but doesnât have a button yet or update any settings]
Edited to say: I now see that your second scan is the first one, but with much improved stitching. It is the same stitching algorithm for preview and final stitch. But it may be that a couple of images confused the fitting until more data was collected to constrain them. The final preview is normally from just before the last images are collected. Nice scan, we just needs to speed up collection!
The HQ probably needs adjusted settings as the colour is more uniform, but the sensor is so large we get too much field curvature. We can probably reduce the overlap, but only once the sensor is cropped a bit further. @JohemianKnapsody has a test branch for a number of HQ changes, but it is still very much in dev. If you want to help with the testing we can help you get your microscope rebased onto that branch.
I am not sure if we will get the HQ changes in for alpha5. We have some low-level structural software changes planned which will ease future dev, but will probably dominate the alpha5 dev cycle.
That is very useful feedback. One issue with being a web-app is these things perform slightly different per browser/system. Can you let us know which you were using. The UI needs some serious tightening up. Iâve made an issue on GitLab for this so t doesnât get forgotten.
Yup, happy to help out in any way I can. Iâll be building a couple of OFMâs soon, so Iâll be testing a bunch, including with the 2.1 camera and with the upright version. I also plan on messing around with the coding, but I canât get sucked into the R&D part of the project before I get the funding proposal finished up.
The colour might also be worse for me because of a low quality lightsource / entire illumination module. I have a high CRI LED that I can replace the one I used, since the one currently in the microscope is some random LED for electro fashion. It wasnât suitable for our otoscopes, so I think it might be having an impact here too. EDIT: also Iâm using a photography diffuser on the LED, not a piece of plastic
Included the fancy tables I donât understand below if that helps
Iâm using a photography diffuser on the LED, not a piece of plastic
We may need to switch to something like this as we have found photodegredation of the polypropelene. The choice was very much the material that I had in my workshop during COVID lockdown, and we havenât had a need to revisit it since. for the LED you just want to ensure that it has a fairly even spectrum, lots have have quite a lumpy spectrum with almost no light at some wavelengths.
Those graphs look as expected. The one with the blue square just tells is the positions the stage took the images at. It is useful for debugging weird settings and strange behaviour.
The other graphs are 1 point per overlapping pair of images.
The y axis the difference in estimates of image displacement between the pair from image registration (correlating images) and from what the stage reports.
the x axis is the quality of the peak, from quite a simple sharpness metric
We use these metrics to decide which images have registered badly by looking at how excluding images affects the RMS of the position optimisation. The left graph shows all pairs and the green region are the pairs we are using for correlation. The right graph is just the green region of the left graph. This is needed if there are a couple of really really bad points in the first graph making the green region too small to look at.
I imagine that earlier it put the cuttoff at something like 6.5 in x and 1000 y. Then all of the outer images are only constrained by the stage position (with adjustments based on image registration positions to stage during the good part of the scan). If there were groups of only stage positions this could have created cumulative errors causing the wonky stitch.
Hi Adam, thanks for sharing this! I think we can save you a lot of time by playing with the default settings a bit. With the HQ camera, I tend to drop the overlap to ~0.2.
Because the area of each image used scales with (1-overlap)**2, that will halve the number of images youâll need to collect. As Julian says, depending on your objective, that might mean we see some field curvature between images, but weâre looking at some software ways to mitigate that, as well as hopefully testing some objectives so that we can make a recommendation for the HQ camera.
If anything here sounds interesting to you, happy to share more about the progress weâve made with HQ camera
I have just burned the image on my SD card, using RPi imager 1.9.6 (anything above seems to have lost access to custom settings? Interestingly, I get the following when I open the server page in Safari (full text below).
Chrome just says it cannot reached, but the ping command goes through just fine⌠What does SystemExit 3 mean? Please help
LabThings Couldnât Load
Something went wrong when setting up your LabThings server.
Please check your configuration and try again.
More details may be shown below:
3
The following Things loaded successfully:
/camera/:
/stage/:
/autofocus/:
/camera_stage_mapping/:
/system/:
/smart_scan/:
/stage_measure/:
Your configuration:
{
"things": {
"/camera/": {
"class": "openflexure_microscope_server.things.camera.picamera:StreamingPiCamera2",
"kwargs": {
"camera_board": "picamera_v2"
}
},
"/stage/": "openflexure_microscope_server.things.stage.sangaboard:SangaboardThing",
"/autofocus/": "openflexure_microscope_server.things.autofocus:AutofocusThing",
"/camera_stage_mapping/": "openflexure_microscope_server.things.camera_stage_mapping:CameraStageMapper",
"/system/": "openflexure_microscope_server.things.system:OpenFlexureSystem",
"/smart_scan/": {
"class": "openflexure_microscope_server.things.smart_scan:SmartScanThing",
"kwargs": {
"scans_folder": "/var/openflexure/scans/"
}
},
"/stage_measure/": "openflexure_microscope_server.things.stage_measure:RangeofMotionThing"
},
"settings_folder": "/var/openflexure/settings/",
"log_folder": "/var/openflexure/logs/"
}
Traceback
Traceback (most recent call last):
File "/var/openflexure/application/openflexure-microscope-server/src/openflexure_microscope_server/server/__init__.py", line 109, in serve_from_cli
uvicorn.run(
File "/var/openflexure/application/openflexure-microscope-server/.venv/lib/python3.11/site-packages/uvicorn/main.py", line 601, in run
sys.exit(STARTUP_FAILURE)
SystemExit: 3
No logging info available
3 means it the server errored during start up but the was error between the place where errors capture normally during startup, but before the place where errors start being captured normally again. I know that is unhelpful, but it is something that has plagued development for us that comes from a library we call.
Normally it is something hardware related. Just to check you have a v2 camera not an hq?
Oh! You are right, I was using HQ camera⌠I have another OFM with v2 camera but I havenât tried it there yet - I will! Is there a way to use HQ camera with v3? Apologies, I saw the amazing scans by @adamglia on HQ camera and assumed that it will work out of the box
Thanks @adamglia, yeah needs an updated config. The config is a little more confusing to do by hand as of the new alpha, but it moves us towards something we can customise with config server.
The eventual plan is to have a config server on a different port so you can always get to that even if the main microscope wonât load to set configurations, reboot the server, turn off the microscope. Hopefully eventually do updates. We need to do a fair number of other things before we focus on that. But rest assured this isnât the plan for the final v3 interface.
I also managed to reliably track down why we have the useless âSystemExit3â today. It is in a library we use, not in the OFM server. I have a fix half ready, which hopefully can get ready for the next alpha. You would still get an error in the current situation, but hopefully one that is more helpful.
Iâm out right now, but tomorrow Iâll try to find the correct configuration to vet HQ working
I found it, the config is in a different place now, which is helpfully documented in the old config I also followed the new naming convention. One just need to change picamera_v2 to picamera_hq here: /var/openflexure/application/openflexure-microscope-server/ofm_config_full.json, it worked right away, going through the calibration now!
I also followed the new naming convention. One just need to change