Hi all I love the v3 server, it is already saving so much time on downloading the images and stitching them. So I don’t want to sound ungrateful when I ask the following question below. I am also aware that similar questions have been asked in the past but the threads are often quite old so I assume things might have changed since. So, here is the question:
What are the ultimate limitations to speeding up the scan even more? Are they mechanical or is it in the electronics? Digital pathology scanners can scan a full slide in minutes (but then they cost 100K and above), so it is technically possible. I’m trying to understand what the crucial barrier for a speed up is. Right now it takes me about an hour to have a 1mm sq area scanned on X40, with default v3 server settings, which leaves 15x15 out of bounds a bit… Also, I don’t know if it is relevant, the motors stay hot even when idle - happy to open a separate topic for this.
Last things first: stepper motors are always powered, which means that they also hold position. This means that they will be warm (or hot - there are also several threads on that!).
Scan speed limits are partly mechanical. Most obviously the maximum motor speed for reliable stepping means that it is of the order of seconds to move to the next field of view. Different motors would allow fast movement.
There is also settling time after motion, to get a still image. There will be ways to get that better, looking at acceleration and deceleration speed and resonances of the structure, as is done for the new faster 3D printers.
The electronics limits are in image capture and processing. For autofocus, the 30 frames per second of the camera preview stream is already a limit for part of autofocus, even with the current slower motors. A higher frame rate and faster image processing would also allow dynamic decisions about things like settling - eg checking that two consecutive images are the same.
@JohemianKnapsody and @j.stirling have cut a lot of dead time from scanning for v3 alpha 2, and I think there still some more improvements still in the pipeline. There are trade-offs for speed and reliability, the less you wait and check, the more possibility there is that something is not correct. That is particularly a problem in focus.
I think, as usual, @WilliamW has covered pretty much everything. I will add a few details:
Autufocus: this is probably where most of our time goes, particularly at 40x when the moves between fields are short. Commercial slide scanners often have either laser-based autofocus, or don’t need to autofocus every time. If we sped up autofocus further it would be a noticeable improvement, probably tens of percent on the current (v3 alpha 2) version. Quite a lot of the effort since alpha 1 from @JohemianKnapsody and @j.stirling has gone into getting the optimised scanning code into the v3 alpha. In particular, combining Z stacking and autofocus has sped things up a lot.
Field of view: this is a big one that makes commercial scanners faster (like 4-10x faster). They use much more expensive optics (and cameras, but the big one is the objective lens) that allows them to image a bigger field of view. That means fewer images for the same area of sample. In principle, you could spend more on optics for an OFM, but we’re talking £1-5k lenses so it’s not a small upgrade, and would put it out of reach for the majority of people who are using it at the moment.
Magnification: my understanding is that most commercial scanners work at 20x, though possibly with a higher-resolution 20x objective than the ones we typically use. That would give performance that’s somewhere between what the OFM gets with 20x and 40x (in terms of resolution). As with field of view, this will be a big speed up, of order 4x or more. Add to that 20x objectives being less sensitive to focus, and you save time there as well.
So, I think the first thing to check is if you’re using alpha 2. It should be significantly faster than alpha 1. I think going a bit faster by optimising software is possible, but we’d be talking a few tens of percent. More than that likely requires different (and more expensive) optics. For lower magnification, using faster steppers (e.g. NEMA motors like you find on 3D printers) could go faster - that might save some time, but perhaps not as much as you’d think.
I hope that’s a useful summary - I think it’s probably safe to say the team is mostly focused on tidying up the existing features/optimisations so we can move v3 to a beta and eventually a release, so nobody is working on these changes at the moment. If anybody is keen to build a modified microscope with faster motors or wider FoV optics, I would be very interested to see one - it won’t make it into the v7 release, but it’s always exciting to think about features that could be added in the future.
Thank you so much for these fantastic answers, @WilliamW and @r.w.bowman ! They help my understanding so much. NEMA motors, faster camera and faster processor with more RAM are probably the direction I will try to move into - it will make the OFM more expensive of course but not as expensive as a fancy objective. I wonder what kind of speed gain one could get combining all these?
Re alpha versions - I am away from my dear OFMs now, how do I figure out which version I used? I downloaded the build on August 8th (2025-08-08-raspios-openflexure-bookworm-armhf-lite-999-final-export.img.xz)… Is it v3 alpha 2 or still alpha 1?
Commercial scanners are moving to 40x by default. The GT450 is a Leica scanner that’s replaced the workhorse AT2 that fed the first wave of digital pathology in the last decade.
It uses 40x and while I can’t speak for other vendors, it’s quite fast. I feel its ability to handle edge cases suffers (especially related to fine focus).
I believe the field of view on commercial scanners isn’t vastly different from what we work with. The other bottlenecks are definitely true.
another critical difference related to autofocus is that these machines have Cartesian stages that shouldn’t have much z-drift between XY positions, unlike the OFM stage that moves in Z as it moves in XY. So they can skip autofocus when possible. Or they have only small AF travels needed for fine adjustments.
I am building a Cartesian stage microscope for this reason but printed plastic has a lot of flex and a lot of bad thermal and vibration properties that make it drift a lot. Haven’t found a great path forward yet without spending a lot of money on precision linear motion hardware or learning how to machine metal
do it think it would be possible to make a laser autofocus system considering its already standard in modern smartphones and esp the iphones , maybe a lidar sensor that can capture real time info in the shift in the point cloud so that adjustments can be made on the fly ? is this a path worth pursuing ? i am a pediatrician with a strong passion for embedded systems , histopathology and electronics , i might also consider applying for a research fund here in india and ofc open sourcing my findings .
One really interesting concept is using self-mixing laser interferometry for tracking sub-wavelength shifts (or counting half/wavelength offsets), if someone could get that working that would be absolutely amazing.
The basic concept is very simple - common and cheap laser diodes have a built in photodiode and reflecting the laser back causes interference inside the laser, which can be seen on the photodiode output. Then some non-so-simple laser magic also makes the values really weirdly shaped so with tuning it can be used to get the position within that lambda/2 cycle too.
I once got it working so I could track a speaker moving but it is very finicky to set up and it might need very fast sampling to handle the vibrations. There are some papers on it and a great video on the applied science channel https://www.youtube.com/watch?v=MUdro-6u2Zg if anyone feels like giving that a go.
A large part of this question is what you mean by ‘focus’. For a really thin and flat histology sample which is pressed against a flat glass surface there is a clear interface that could be detected by a laser based system. This could potentially be done very quickly as it is not limited by camera frame rate. There would need to be a separate calibration step to co-locate the laser definition of focus and the camera focus. It would provide a considerable speed advantage in well-defined workflows.
In many samples there is actually some depth, or the sample is thin but is not necessarily flat against the interface. In these cases it is hard to define a position that the laser can latch on to that defines ‘in focus’. The jpeg-based imaging autofocus is more robust in these cases. The jpeg compression algorithm is designed specifically for images presented to humans, capturing the detail that humans think is important in images. This means that there is usually very good agreement between the best focus as defined by jpeg size and the best focus as defined manually.
I think time-of-flight would not work here: it’s great for photos (where you need resolution in depth of ~10cm) but not useful for microscopy (where you need resolution in depth of <1um). Unfortunately, unlike the various geometric techniques where axial precision improves with magnification, time-of-flight measurements (which are, I think, what most smartphones do) don’t improve with magnification.
Using a laser-based solution (either interferometric as Filip suggests or just oblique angled) is much more likely to work, I think.
I got as far as prototyping (with one print) an XY stage that was more linear, but never got it working well enough to use. I think the parasitic Z motion we have is often predictable enough that we can get away with a relatively small autofocus/z stack range - but once you’re at 40x the depth of field is short enough that it’s hard to imagine eliminating the focus step completely, even with quite an expensive mechanism.
What’s the relative speed penalty for recording a Z-stack vs autofocus? One could imagine that the in-focus image could be selected in the background rather than waiting for AF, meanwhile the acquisition has moved on.
I’m sure this isn’t possible with our current hardware, but it might be a reasonable strategy if recording and storage and multithreading was fast and cheap.
I believe @JohemianKnapsody has implemented this in the “smart scan” code: the default behaviour is to take a shallow Z stack, and keep the in-focus image. It does indeed speed it up significantly. It only performs a full autofocus if that initial Z stack fails to find a sharpness peak in a small number of images (which suggests the focus has drifted further than the range of the Z stack). He may correct me if I’m wrong here!
There are some challenges around holding many images in RAM on a small device like the Pi, but it’s possible provided the Z stack is not too many images.
I love the v3 server, it is already saving so much time on downloading the images and stitching them. So I don’t want to sound ungrateful when I ask the following question below. I am also aware that similar questions have been asked in the past but the threads are often quite old so I assume things might have changed since. So, here is the question: