It is still some way off.
Richard has made great progress over recent months, however to really make good progress we need more dedicated software development. We have put a grant application to try to get some funding directly for the software, and we are also in the process of trying to establish some sort of entity outside academia that can focus on the aspects of the microscope development that fall outside the definition of “research”.
V3 images are available for testing. But they are not yet feature complete, all of them are the Lite version of the OS. Once, we get up a bit more steam, I hope we can scale the user testing and feedback on the forum.
4 Likes
For anyone interested in progress on the new server. @JohemianKnapsody and I have made quote a lot of progress adding features and tidying up the server and stitching codebases. We have also added a fair bit of functionality from Joes testing branches into the v3 branch. With code review help from @bprobert
Highlights:
Hopefully we are not far away from semi-complete alpha release. Test versions of the OS are available here:
I have updated the architecture diagram a bit and added in repository URLs:
We plan to go through and label issues on some of these repositories that we think are “low hanging fruit”. In the hope that this helps potential contributors find issues that are a nice way to ease into the codebase.
2 Likes
Will version 3 support capturing lossless data? The current method of storing bayer data in the EXIF is weird, and it’s not obvious to everyone that the bayer data in the EXIF file is not the same as the data you look at when you open the JPEG. Providing either the 10-bit bayer data or 10-bit RGB data in a lossless format would be much appreciated. Formats such as 16-bit PNGs, EXR, or (although it’s my least favorite) TIFF could do this.
Edit: I had a look at the source code of the v3 branch and as of this writing, it looks like you guys are using OpenCV now. I’d like to suggest that the rasberry pi 2 camera interface be used instead, so that you can allow users to capture the full 10-bit resolution of the camera. You can bit shift the data into a 16-bit data type and encode it in a PNG for portability. PNG supports EXIF, so you can add metadata to it as you do with JPEG.
Edit 2: I was mistaken about OpenCV being the primary interface, see comments below.
2 Likes
Sorry for the confusion. the OpenCV camera is in there as is a simulation camera but the picamera use by default is in another repo. In the above diagram it is GitHub#3.
This is something I really want to change because the labthings-picamera2 depends on following the protocall in the OpenFlexure Microscope Server, and the Server depends on labthings-picamera2. The plan is to pull the camera interface out entirely into a consistent Repo.
As for Raw images, this is something we haven’t discussed in huge detail. Much of the v3 development has been getting a stable picamera2 interface, we have had issues with weird colour effects for red images (was a quirk of green equalisation) camera timeouts that hard crashed the pi (turned out to be timeout miss-matches at the software and python level by default), and number of other memory related issues relating to the live stitching while scanning.
We have made great strides with all of these, and now have a branch soon to be merged which has scanning reliably collecting 8MP captures which it downsamples to 2MP. This is done because the optical resolution is a bit below 2MP, but by collecting at 8MP each of the 4 bayer channels is 2MP. We then perform the demosaicing into 8MP and downsample to 2MP. This improves quality compared to 2MP capture.
I assume RAW will be an optional setting in both scan and capture. In the case of scanning it may slow things down due to the speed of saving to disk. If you are on GitLab can you add an issue saying that you would like RAW capture, and how you would refer the data to be saved. This way it will be tracked and won’t get forgotten.
1 Like
I see, thanks for the clarification. I don’t understand what a lab thing is, but it sounds like there’s been work utilizing picamera2 and that’s great to hear! I’ll make a gitlab issue regarding the preservation of access to the 10-bit bayer data in a lossless format.
1 Like
LabThings is a framework that we made to allow us to use the WC3 standard for Web of Things. Basically we have a web server, and that web server is connected to multiple bits of hardware each which need to be controlled. LabThings allows us to control them together, but also to expose their functionality and/or state as a webAPI.
Some more detail is here:
https://royalsocietypublishing.org/doi/full/10.1098/rsos.211158
Got it. Reminds me a little bit of ROS, except this looks way better and it doesn’t use DDS.
1 Like
