Simple rotation/translation stitching

346 views
Skip to first unread message

Any One

unread,
Aug 28, 2017, 12:22:37 PM8/28/17
to hugin and other free panoramic software
Hi,

I have a series of old maps that were scanned in.  Each map has four scanned images comprising the map since the map dimensions were larger that the scanner flat bed.  I have tried to stitch the scans together but I am getting significant breaks in the resulting image.  Image overlap.gif is a typical composite of the four images.  There is sufficient overlap in one direction but minimal in another.  Image discontinuity.gif illustrates the resulting image break where there is minimal overlap.  The steps I have used were

1. Under Images:
   Load images
   set HFOV to 10
   set anchor desired image for position and exposure
   select CPFind and create control points
   select auto tune all points under edit tab; remove/fix bad control points
2. Under Camera and Lens:
   create new lens for each image
3. Under Optimizer:
   select Custom parameters below
   remove yaw, pitchand roll constraints
   select x, y and z for the non-anchored images
   select optimize
4. Under Fast Panorama preview:
   select projection tab
   select fit
   select Rectilinear in selection box
   select Move/Drag, adjust image
   select Crop, crop image
5. Under Stitcher
   select Calculate Optimal Size
   select stitch

Hugin appears to be very capable but in this case, I would say that simple rotation and translation would suffice with a basic gradient blending across the boundaries to smooth the seam since the overlapping regions are essentially identical. This can be accomplished in gimp but is time consuming.

Can someone assist me here with advice with hugin or suggest another piece of software that would facilitate the stitching?

Thanks.

Al
overlap.gif
discontinuity.gif

T. Modes

unread,
Aug 29, 2017, 11:20:56 AM8/29/17
to hugin and other free panoramic software


Am Montag, 28. August 2017 18:22:37 UTC+2 schrieb Any One:
2. Under Camera and Lens:
   create new lens for each image
This is not necessary when you don't optimize lens parameters like HFOV (but even in this case it would be easier to unlink HFOV instead of create different lenses)

3. Under Optimizer:
   select Custom parameters below
   remove yaw, pitchand roll constraints
   select x, y and z for the non-anchored images
   select optimize
You would not remove roll from the parameters to optimize. There can always be a slight rotation between different images.

4. Under Fast Panorama preview:
   select projection tab
   select fit
   select Rectilinear in selection box
   select Move/Drag, adjust image
   select Crop, crop image
First change projection and then use fit+move+crop.

5. Under Stitcher
   select Calculate Optimal Size
   select stitch

Hugin appears to be very capable but in this case, I would say that simple rotation and translation would suffice <snip>
But this would require a rewrite of big parts of Hugin (optimizer, remapper).

Gunter Königsmann

unread,
Aug 29, 2017, 11:51:49 AM8/29/17
to hugi...@googlegroups.com
You want to optimize x,y and r, not x,y and z.

Kind regards,

  Gunter.

--
A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ
---
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hugin-ptx+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/705052ad-6071-4268-8b21-a031646bd989%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Rogier Wolff

unread,
Aug 29, 2017, 12:02:11 PM8/29/17
to hugi...@googlegroups.com
What I suspect he means is that it would be nice to be able to select
"simple rot/trnaslate only" say in the assistant. Would that require
an essential rewrite???

Roger.

--
+-- Rogier Wolff -- www.harddisk-recovery.nl -- 0800 220 20 20 --
- Datarecovery Services Nederland B.V. Delft. KVK: 30160549 -
| Files foetsie, bestanden kwijt, alle data weg?!
| Blijf kalm en neem contact op met Harddisk-recovery.nl!

Gunter Königsmann

unread,
Aug 29, 2017, 12:28:23 PM8/29/17
to hugi...@googlegroups.com

> What I suspect he means is that it would be nice to be able to select
> "simple rot/translate only" say in the assistant.
And it would be nice to be able to specify instead a "field of view" the
information "scanned images" that automatically applies a new lens to
each image and tells the program that the images are essentially flat.

Just dreaming...

T. Modes

unread,
Aug 29, 2017, 12:47:11 PM8/29/17
to hugin and other free panoramic software


Am Dienstag, 29. August 2017 18:02:11 UTC+2 schrieb r.e.wolff:
What I suspect he means is that it would be nice to be able to select
"simple rot/trnaslate only" say in the assistant. Would that require
an essential rewrite???

The assistant is currently fully automatic. This would require to detect this case automatically, but how?

Gunter Königsmann

unread,
Aug 29, 2017, 1:18:02 PM8/29/17
to hugi...@googlegroups.com
If there is no field of view it asks so my dream of the possibility to specify "scanned images" here might not be this bad for this situation...

--
A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ
---
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hugin-ptx+unsubscribe@googlegroups.com.

Roger Broadie

unread,
Aug 29, 2017, 2:35:10 PM8/29/17
to hugin and other free panoramic software
Well, a number of interesting comments have come in, but there is still room for more, especially as I can offer an example

It seems to me that you have a good handle on the process, though of course the discontinuities you show are frustrating.  As it happens, I have a set of scanned images of a map that has rather less overlap in one direction than I would like.  Even a second go did not eliminate all problems and there are areas in the final stitch where the original was bent at the edges and resolution and illumination fell away.  I could partially, but never completely, eliminate them by masking and I am sure the best course would have been to add in extra scans that covered the difficult areas.  However these admitted defects are not really relevant for this exercise and it sounds as though you already have your scanned images and have to make the best of them.

My interest was not so much in scanned images, though no doubt scanning is the best way to capture the detail, but rather maps photographed in sections with a hand-held camera mostly pointed as directly downward (i.e. normal to the map) as circumstances permitted.  For this setup Hugin's translation model works well, with y, p and r to deal with the direction in which the camera points and X, Y and Z to deal with its position for each image.  But scanning should simplify the situation by eliminating the need for optimising y and p - and so it proves.  I attach a screen shot of the optimiser tab for my test case and a reduced image of the outcome, viewable here:


This optimisation is the most basic I could find and in practice I would probably add various refinements to improve the optimisation figure. Nonetheless, the average control-point difference in pixels is still only 0.9 and the maximum 2.0.  That is at the optimum resolution determined by Hugin, which corresponds to an image of roughly 19000 × 12000.

Something needs to be done to anchor the angular orientation of the entire image.  Here I simply set the roll of image 0 at 90 deg, to compensate for the orientation produced by the scanner I used.  That value seems to work well enough.  I see you rotated the image by hand. That also works, with care.  However, normally I add horizontal and vertical control points, especially when, as in my example, there is a clear framing border.  Allowing the angle of roll to be optimised with respect to some reference is very important for scanned images, where, as I think someone pointed out recently, some variation in the angle in which the original is positioned on the scanner seems inevitable.

There's no magic in the value I gave for the hfov, namely 20 deg.  It's pretty arbitrary.  But I think it is generally important not to allow it to be varied if Z is to be optimised.  In the case of the normal camera image, you can vary either the fov or Z to compensate for zoom, but allowing both to vary can give problems..  I'm not sure what reality Z might represent for scanned images, but optimising it does seem to help significantly.

I am wary of using individual lenses if there is no clear difference in the lens, or its equivalent (i.e. the scanner).  As my example shows, it is not necessary.  My suspicion is that, though it sometimes does seem to be recommended for flat stitches, it is a hang-over from the time before translation parameters were included.  I certainly used it myself.  But I don't think, overall, it represents a set of lens distortion parameters that apply in the case of each individual image. Rather, it has the effect, at least partially, of simulating an angled lens, which in any case does not apply to scanned images.  But I may be missing something.  I wait to hear.

I wonder if using different lenses is at least part of the cause of your discontinuities. I do note that the two sections of plot boundary on either side of each discontinuity do not share a common direction and, indeed, as one moves from one discontinuity to the next, the relative angle between the sections seems to change.  If you are to use individual lenses the normal recommendation is to have lots of control points widely spread across the whole image produced by that lens and that might be difficult where, as in your case, there is little overlap.

Of course, long linear features can offer control-point detectors difficulties if there are no distinguishing details on or near them. But in the case of your image showing the discontinuities the seam clearly passes near or even through plot numbers and they should give control-point detectors something to bite on.  Thus you could try dragging a rectangle around them and selecting that great standby "create control points here": see e.g.


Or, of course, you could add them by hand, assuming they are not there already.

There is another possibility for mending these discontinuities, although I have to admit I have only used it once.  I depends on the fact that the plot boundaries in your case look pretty straight near the discontinuities.  Go to the control points tab and, for each of the two images between which a discontinuity shows, define a new line which uses the same number in the two images and, as far as possible, spans the discontinuity.  Indeed, several of these spread along the band of discontinuities may be enough to push the optimiser into aligning the various pairs of sections.

Roger Broadie
Optimiser tab.jpg

bugbear

unread,
Aug 30, 2017, 4:38:52 AM8/30/17
to hugi...@googlegroups.com
Roger Broadie wrote:

> Of course, long linear features can offer control-point detectors difficulties if there are no distinguishing details on or near them. But in the case of your image showing the discontinuities the seam clearly passes near or even through plot numbers and they should give control-point detectors something to bite on. Thus you could try dragging a rectangle around them and selecting that great standby "create control points here": see e.g.

I often (ish) use my camera and a pano head as a substitute for the A0 scanner I don't own, usually
for maps and newspapers.

In both cases I do NOT use automatically generated CPs. There is so much fine scale
repetition in text (all the printed characters are identical) and a map (symbols, text again)
that false hits are inevitable.

For truly large items, I don't use a pano head, but move the entire tripod and camera over
the item, grid-fashion. This is laborious to do, and laborious in hugin too.

BugBear

Roger Broadie

unread,
Aug 31, 2017, 5:16:22 AM8/31/17
to hugi...@googlegroups.com
Adding all control-points by hand hardly bears thinking about. I
often have to add some, but I think I have always had at least a
substratum of automatically generated cps. My problem with old maps
is not the one you mention. Rather, it is that they are often faded
and photographed in low-level lighting and thus rather indistinct,
which can defeat automatic systems, though the human eye is prepared
to make a judgment about the best correspondence. And sometimes there
are features like bushes along field boundaries that are
conventionally spaced and mislead the cp finder.

But these considerations should apply less to scanned images and I
didn't need to add any to the example I showed of an old(ish) map of
the Ipswich area. Rather, I had to prune a few that CP Find had
delivered. Admittedly, I had helped it by getting the constituent
images roughly into position by hand before invoking it.

Roger
> --
> A list of frequently asked questions is available at:
> http://wiki.panotools.org/Hugin_FAQ
> --- You received this message because you are subscribed to the Google
> Groups "hugin and other free panoramic software" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to hugin-ptx+...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/hugin-ptx/59A6798D.9080006%40papermule.co.uk.

bugbear

unread,
Sep 4, 2017, 5:14:14 AM9/4/17
to hugi...@googlegroups.com
Roger Broadie wrote:
> Adding all control-points by hand hardly bears thinking about.

What would you think of 2114 hand placed CPs on 173 8Mp images?
It's optimised under YPR/XYZ, and an optimisation run takes around
an hour on my laptop. I don't like to talk about the stitch time.

In a bid to stay sane, I did a lock of locking of some image,
whilst adding and optimisation new images.

At any one time, only a few (20-30) images were visible, of which the older
ones were locked.

:-)

BugBear

Reply all
Reply to author
Forward
0 new messages