We do read from the metadata, but it is a somewhat annoying to do with Exiftool due to the encoding.
If there is no EXIF data we look at the file name, so if it is image_100_-300.jpg Then we will know it is x position 100, y position -300. If there are 3 numbers then these are treated as x,y,z.
I think the first issue is that your images are slightly different sizes.
The second one is it doesn’t think any of the images overlap. This may be because they have the same metadata, but the images are now smaller. What does stitching_inputs.png look like. If it shows images that are laid out in a grid but not overlapping then this is what I think is happening.
Sorry for the really poor quality error messages, there is still some work to do making the code base user friendly.
@j.stirling Thank you so much for your support! You are correct, the focus-stack’ed images are indeed slightly different in size. Unfortunately, looks like the option of keeping the resulting file same size is not part of a stable version yes, and I am having trouble building the pre-release (Releases · PetteriAimonen/focus-stack · GitHub)
The stacked images are not too far off from the original sizes (3280 x 2464) so I thought maybe I can just resize them using Image package from PIL. But the resulting stitched image looks surprising… My files are called like this: 2025-05-12_21-02-22_-2000_2000_18135.jpeg, the z-axis is just the mean of all the z-coordinates that went into the stack. As a toy example I use only 9 stacked images. If I alight them by hand (last attachment), it looks ok-ish (to my naive eye), but openflexure-stitch seems to have developed taste for abstract art
Here is its output of the command:
Finding a list of all overlapping images
Getting all the image info ready to stitch
Plotting the inputs to stitching
Finding the optimal threshold
Starting with 6 possible peak quality thresholds and 6 possible stage discrepancy thresholds
After filtering and resampling 6 peak quality thresholds and 6 stage discrepancy thresholds will be trialed for fit quality.
Using 6 of the 6 pairs for final optimisation
After thresholding the only image pairs that remain are all vertical or all horizontally paired. Thresholding or other input settings need adjusting
Yes something is going wrong there. When did you download stitching? We have done a fair bit of work recently, a newer version may work better, it may at least be easier to debug as it is more modular for running in a notebook.
If you are running from commandline I would look at changing the highpass filter value as it looks like the correlations are way off.
Instead of resizing the images, it may be easier to crop them if it is a pixel or two?
I have made a fresh install of focus-stack, latest release, now the images are no longer resized, there is an option for that. My instal of openflexure-stitch is also from today, just to be sure I reinstalled it on my not too old mac (2.5y). Just two images from neighbouring stacks get stitched together perfectly, but more than two results in this horizontal stitching. I’ve tried various --high_pass_sigma values, from 1 to 15, no luck… I wonder what focus-stack is doing to the images? Because a set of images from a simple x-y scanning get stitched perfectly without a hiccup, it is just sadly I really need to scan as much depth as possible… I can share a gDrive folder with the images if it helps, the original ones from OMF and the z-stacked ones. Thank you for your help!
I’m happy to take a look if you upload them. It may be that focus stack makes areas that no longer correlate that well. In that case what we might be able to do is run stitching on the original image set, back out the positions and stitch the focus-stack images based on those, would be interesting to see how good that looks.
Thank you, @j.stirling! I have put the images here, there are two folders - one with “raw” images, there are 20 per x-y location, 160 in total. I used full resolution option to save them when doing the scanning. The other folder has but 8 z-stacked images from the focus-stack, the size is the same as the original images. I also kept the output from openflexure-stitch. Very curious what you will find out!
And your suggestion on running the stitching first on the original image set and using the position on the z-stacked set of images sounds great too, I want to try it. For the sake of speed shall I pick up the z-coordinate closest to the middle, as it is likely to be the sharpest one overall, I guess it will help finding the correlation spots? How do I go about it? Do I just provide the path to OFMTileConfiguration.txt file in the --csm_matrix parameter when I run the openflexure-stitch the second time, on the z-stacked files?
Glad to see you’ve been able to have some useful conversations without me! As Julian says, getting the stitched positions before stacking sounds like it’d work, at least +/- a couple of pixels depending on how well the images were collected (if there was any drift in xy during the z movements). I don’t think there’s currently a way in our software to use the locations of a previous stitch to position new images.
To test if the approach works, you can do the first stitch, which generates a OFMTileConfiguration.txt. Then stack your images, giving them the same name as the images you used to stitch. Then Fiji Stitching plug in will be able to make a stitched image from those images and your OFMTileConfiguration.txt, if you specify Positions from File and deselecting Compute Overlaps. We’ll also open an issue for generating an image from OFMTileConfiguration.txt.
It’s nice to have a good dataset with z-stacking, I’ll try to poke stitching so that it works well with the datasets. May be a while before I find time.
@evolk I assume it takes ages to run on the dataset (or did it the first time) on the newest OpenFlexure Stitching?
When we refactored a number of things I temporarily removed z-stack detection, and as such it is correlating everything that overlaps. As you have so many overlaps (because each image in the stack overlaps all the ones in its stack and its neighbours) it has to do 12720 correlations.
Or did you manually pick out the sharpest in each stack. I’ll try to get z-stack detection back in this morning as we want to do a release of an updated stitching very soon.
Edited to add
I have made something to filter the z-stack so now it runs much quicker. I do have an issue where the camera to sample matrix I get is off by a factor of 4 from what I would expect. I am not sure if that was a bug in the server, or if you have changed objective since running camera stage mapping?
In the file the CSM is:
[[-0.490, -18.32],
[-18.94, 0.333]]
as the width it was calculated with is 1/4 of the image resolution this converts it to a CSM of
[[-0.124, -4.64]
[-4.80, 0.084]]
This is still approximately wrong by a factor of 4. I can fix this by entering --csm_calibration_width 210 when I run openflexure-stitch. Even though it is fixable it would be good to understand what is wrong.
Sorry about the delay, I was swamped with work which sadly does not even involve microscopy
@j.stirling This looks great! And I did change an objective recently, from x10 to x40, but I am pretty sure I rerun the calibration… But I will doublecheck! I am thinking to try x20 objective anyway because it is a good tradeoff between the resolution I need and the time it would take to scan the whole sample)
I did try picking the sharpest image from every set of same x-y coordinate but my results didn’t look as good, and Fiji was totally confused when I tried to apply the OFMTileConfiguration.txt to the z-stacked images, but now we probably know the reason - the wrong magnitude in CSM!
Regarding stitching time - one of the reasons I want to try x20 is because I would need fewer images to cover a lot of surface. What is the maximum number of images openflexure-stitch can effectively deal with? Because the number of comparisons is approximately quadratic to the number of images, right?
@JohemianKnapsody has sone some HUUGE scans with a final output size of about 2giga pixel. It is worth using --resize 0.25 for large scans on 8MP as this only resizes for correlations not for the final stitch.
We have an update being worked on now that auto filters the z-stack and also does much more memory efficient stitching
If 20× does work for you, then it is worth trying the ‘low cost’ optics module along side a 20× objective. The images are usually very good, and if it fits your need then it means that there are fewer parts to obtain - no tube lens as well as no objective.
Apologies, @WilliamW, I made a rookie mistake, I should have said that I am going to try x20 objective, together with the other lenses in my high resolution OMF I measure (with a tailor tape to the screen no less) around x250 magnification when using what I call “glass ruler” with 0.1 and 0.01 divisions. x200-x250 seems to be exactly what I need, large enough to see amoebae and hyphae but not soo large that scanning takes an overly long time.
That is what I thought you meant. There is a thread directly comparing the ‘low cost’ optics against the high resolution optics module with a 20× microscope objective (not a particularly high quality objective). The field of view and resolution are very similar to eachother Comparison of a pi-camera and a 20x optical lens
Overall magnification depends on your screen size of course. I was presenting at a conference last year, the microscope images were on a screen about 20metres diagonal…
Thank you @j.stirling, the --resize tip is great, I have just stitched over 400 images together in no time! I am curious, would you advise to install openflexure-stitching directly on the raspberry pi? And then run stitching remotely via a terminal? Copying the images over via scp takes a bit of time.
I think this will be my next build, thank you @WilliamW! I have already ordered more filament. Potentially, I am looking to build 10 to 20 OFMs to parallelise things.
I think am getting better at this. I need to scan slides relatively fast, so currently I went down even to x10 objective. Let’s see it this will be sufficient for my purposes, but I can scan most of the 18x18 slide in a snake pattern of 11 cycles with step size 8000. Without z-stacking and with fast focus, OFM takes about 2 hours, which is acceptable for my project.
I am also going to try smaller cover slides and higher resolution - it is important for my project to be certain the full slide has been scanned but in reasonable time, because it is a wet mount sealed with nail polish
Many microscopes working in parallel is one of the possibilities that are opened up by the small size. If you do actually do that it would be great to see pictures
Am I the only one who thinks that this is incredibly slow. We are talking about 120 pictures here, right? So a whole minute per picture? What is taking so long?
