Stitching photos from microscope with Hugin

536 views
Skip to first unread message

allelopath

unread,
Nov 20, 2014, 8:13:25 PM11/20/14
to hugi...@googlegroups.com

I'm having difficulty stitching photos taken from a camera through a microscope. I've stitched plenty of photos using Hugin, but this is different. Apparently the lens normally imparts information such as focal length such that Hugin knows how to stitch. With the microscope, however, there is not a lens, but rather an adapter. This one:

http://www.microscopenet.com/microscope-adapter-nikon-olympus-dslr-with-lens-p-181.html

When loading the images, Hugin asks me to manually enter a focal length. I have no idea what to enter, but with some experimenting, its around 22. This produces a recognizable but not usable image.

Example images are here:

http://imgur.com/a/i1coA

Can anyone give me advice on how to do this?

David W. Jones

unread,
Nov 21, 2014, 3:48:19 AM11/21/14
to hugi...@googlegroups.com
Hmm, maybe try selecting the photos in your ordinary folder view of them
(outside of Hugin), right-clicing and opening them with Hugin's PTO
Generator? Doing that frequently gives me a PTO with an appropriate
focal length.

Would love to see a pano of a microscopic scene!

Another option that sometimes works for me: don't enter a focal length.
just click OK (or whatever button, I forget which). Hugin will then load
the photos and determine a focal length on its own.

--
David W. Jones
gnome...@gmail.com
wandering the landscape of god
http://dancingtreefrog.com

Terry Duell

unread,
Nov 21, 2014, 4:04:10 AM11/21/14
to hugi...@googlegroups.com
Hello,

On Fri, 21 Nov 2014 12:13:25 +1100, allelopath <qhosi...@gmail.com>
wrote:
I had a look at your images, and a try at stitching. The result, along
with the .pto are attached.
I didn't go to much trouble, I simply wanted to get an idea of the
problems.
I used a 10 deg fov, and assumed a rectilinear lens.
CPFind only found control points between centre and right, and I had to
add CPs for left and centre images.
The result isn't too bad.
So, not knowing what the correct data for the lens really is, optimising
for position only using a 10 deg FOV doesn't do a bad job.
I suggest you experiment a bit.
The only real problem I see with these images is that the detail is not
well defined and CPFind has trouble. A bit more overlap may help, if
that's possible.
Hope that helps.

Cheers,
--
Regards,
Terry Duell
terry10degfov.pto
terry-10degfov.jpg

Roger Broadie

unread,
Nov 21, 2014, 7:04:55 AM11/21/14
to hugi...@googlegroups.com
allelopath <qhosi...@gmail.com> wrote on Thu, 20 Nov 2014 at 17:13:25
-0800 (PST)
-----
-----
Surely the point is that a set of microscope photos taken by moving the
slide under the microscope is more akin to a set of scanned images than
to a set of photos taken from a central viewpoint. That means that the
focal length/fov of the original images does not play the same role in
controlling how the images are spread onto the panosphere during
optimisation and it should be possible to stitch the images using the
small-angle approximation under which the fov is set very small so as to
give the effect of a camera at such a great distance that the rays are
effectively parallel.

That approach does indeed work. I set the fov (arbitrarily) at 0.5 deg
and the set stitched well - see CLRsa.pto and the result CLRsa.jpg, both
attached. You have to ignore Hugin's warning that the field of view is
so small that the result is probably invalid. And the optimisation
results do not show automatically. They do show in the Fast Preview
window if you click on the Assistant tab.

I did add lens optimisation, which helped a bit but did not alter the
fov. An fov of 1 degree also worked, and as we see from Terry Duell's
stitch, an fov of 10 deg also works pretty well, which shows that the
small-angle requirements are not too stringent.

I had a brief look at doing the stitch as a photomosaic by including the
translation parameters. It did work, with a slightly better mean error
at the cost of a slightly worse maximum error, but I think - I have not
looked into this very hard - you still need to set the fov of the
individual images at a small value. So it is probably not worth the
effort as long as the microscope points accurately along the normal to
the slide.

Roger Broadie



CLRsa.jpg
CLRsa.pto

Marius Loots

unread,
Nov 21, 2014, 7:34:34 AM11/21/14
to hugi...@googlegroups.com
Hallo Allelopath,

Friday, November 21, 2014, 3:13:25 AM, you wrote:
allelopath> I'm having difficulty stitching photos taken from a camera through a
allelopath> microscope. I've stitched plenty of photos using Hugin, but this is
allelopath> different. Apparently the lens normally imparts information such as focal

It is relatively easy and you get good results. This is a workflow I
use, written up (in 2007) for an older version of hugin, but easily adapted for
the newest versions. As mentioned, it is based on the tutorial for
scans. I am not at the moment able to update for the
newest version, but have added some comments in brackets where I can
remember changes from the older version. Will update as soon as I can.
With hugin 2013 things have changed radically, and I suggest using
2012.

---------------------------------------
I am stitching microscope images on a daily basis and think I have
sorted out most of the glitches in this regard with the current
version of hugin on the windows platform. The results can be seen at:
http://histoweb.co.za/
Not all of these are stitches, and this is a scratch-pad of projects,
but look at the links labeled "Lae vergroting" or "Oorsig".

This is the workflow I follow, based on and modified from the
scanning tutorial at http://hugin.sourceforge.net/tutorials/scans/:

1. Software used: Windows XP, Hugin 0.7 beta 4, autopano 1.03 and
enblend 3.0
(now using the 2012 version of hugin and on a newer machine; hugin
2013 has changes in the layout that makes the workflow a lot more
difficult for slides; using hugin's CPFind without Celeste and NOT
looking for vertical control points. Steps 2, 3 and 4 is skipped and
control points generated after step 10)

2. Images: 2880 x 2304 pixels in all sorts of orientations and
directions. I have used both tiff and jpeg but have settled on jpeg
in favour of smaller initial sizes as a compromise in favour of
storage and handling. The quality difference are small if not
unnoticeable.
(faster pc now means faster stitches, so image dimensions not relevant
anymore)

3. Place all images into a directory together with autopano. Run
autopano with the following command: autopano.exe /project:hugin

4. Open the resulting project file in hugin

(drag and drop images into hugin,


5. Go to the Camera and Lens tab.
6. Select all the images.
7. Change degrees of view to 40.
8. None of the inherit boxes are ticked and all values are 0. Focal
length and crop factor will change to some value, which I ignore
(out of ignorance?).
9. Go to the Stitcher tab.
10. Change projection to rectilinear, Field of view Horizontal to 90
and Field of view vertical to 90.

(generate control points here)

11. Go to the Optimizer tab.
12. Select Custom Parameters.
13. Clear Yaw (y), Pitch (p), Distortion(a), Barrel (b) and Distortion
(c).
14. Select all images EXCLUDING the anchor image for each of roll (r),
view (v), x-shift (d) and y-shift (e). The anchor image will, in
each case, be the first image in the column.

In my setup this display the bug where, in the lens parameter
sections, all the images are labeled as the total number of images
in the project. But as the anchor image is the first in the
column, it is easy to tick the other boxes. I have never
experimented with making any of the other images the anchor, as my
process works fine for me.
15. Optimize.
16. The results are never 100% on, but am average control point
distance of more than 5 means something is wrong. Also see note
below on stitching many images.
17. Preview the result.
18. In the preview, NEVER touch the center icon.
19. Click the Fit icon to see the complete image.
20. Adjust the sliders if necessary to see all the edges of the image.
21. Go to the Camera and Lens Tab and select the first (anchor) image.
22. Adjust the Image Center Shift - Horizontal (d) and Vertical (e)
values to move the image across the field of view to get the
complete image into the center of the field. Optimize after each
adjustment and check the result.
23. Go to the Stitcher Tab.
24. Click Calculate optimal size.
25. Output options Image format: TIFF
26. Output options: Soft Blending
27. Compression LZW (although the result is not compressed).
28. Click Stitch now!

If you have a large number of images (large being an undetermined
number that I have been unable to quantify, the result will look
distorted. In this case, there are two approaches that I have
followed.

Case 1.
1. Optimize and accept the result.
2. Preview the result.
3. Click on the None Icon to remove all images, then add Image 0 and
Image 1, by clicking on buttons below displayed images.
4. In the Hugin preferences, Misc Tab, make sure to tick the box that
says Optimize and stitch only images selected in preview window.
5. Now Optimize as described above.
6. Go to the preview and add the next image.
7. Optimize, Preview, Add next, Rinse, Repeat.
8. As a final step, adjust the Image Center Shift as above.

Case 2 is the same as above, except do no optimize to start. Preview
and select just image 0 to optimize. Then add image 1, and so on.

Unfortunately I cannot speak for a Linux system. This has worked very
well for me and others could probably use this information. The
workflow did change between this and the previous version. I think the
main reason for that being the default boxes that are checked. I also
found that using autopano from inside hugin gave bad results. Exactly
why I have no idea, and unfortunately don't have time to look into
that now.
------------------------------------------------------------------




Groetnis
Marius
mailto:mlo...@medic.up.ac.za
--
add some chaos to your life and put the world in order
http://www.mapungubwe.co.za/
http://www.chaos.co.za/
skype: marius_loots

Hierdie boodskap en aanhangsels is aan 'n vrywaringsklousule
onderhewig. Volledige besonderhede is by
www.it.up.ac.za/documentation/governance/disclaimer/
beskikbaar.

Terry Duell

unread,
Nov 21, 2014, 4:39:15 PM11/21/14
to hugi...@googlegroups.com
On Fri, 21 Nov 2014 20:03:27 +1100, Terry Duell <tdu...@iinet.net.au>
wrote:


> The only real problem I see with these images is that the detail is not
> well defined and CPFind has trouble. A bit more overlap may help, if
> that's possible.

I had a bit more of a think about this, and assuming that the camera lens
is normal to the slide, and that the slide is moved in X and Y, it should
be optimised for positions and translation.
I also did a minor amount of post processing on the images, a little
sharpening on a couple and adjustment of levels to bring out the detail a
little more, and this allowed CPFind to find control points in all the
overlaps. This time I used a FOV of 1 deg, and the result is a better fit.
So, it does look as though you need to use a small FOV.
Optimising for positions and translation should be sufficient.
You probably need more overlap than was provided for this project.
Images of similar subjects may benefit from some post processing to
enhance detail, prior to hugin, to assist CPFind.
Fast Panorama preview_001.jpg
img_0001 - img_0001_02.pto

Roger Broadie

unread,
Nov 21, 2014, 5:51:05 PM11/21/14
to hugi...@googlegroups.com
I wrote earlier today suggesting that stitching the microscope images
using the translation model might require assigning a small field of
view to the individual images. I'm going to backtrack on that. I have
realised that I had failed to notice that the projection was set at
equirectangular. With a small field of view for the individual images
there was no noticeable difference between these two settings, but when
the fov was large it showed. When I corrected that setting for the
translation model it came out fine with an individual fov of 50 degrees.
So I am back to thinking that for the translation model the fov of the
individual images really isn't all that important.

For the small-angle optimisation, of course, it does matter that the
angle is at least small, and that approach remains sensible, it seems to me.

I attach a pto file for the 50-degree case and, for the record, a
revised file for the small-angle approach.

Roger Broadie

CLRsa1.pto
CLRpm 50deg.pto
Reply all
Reply to author
Forward
0 new messages