Incrementally building a photomosaic?

[John Muccigrosso]

I have about a dozen photos, overhead shots taken of an area. They don't cover all of it, so the final output is going to be a little weird looking. Hugin finds a lot of control points attaching the photos one to another, but the final output is very poor (in fact the fast preview shows the artifacts mentioned here).

I started instead with just two photos and that stitch went fine, so I'm thinking it might just be simplest to work through the set incrementally (though it may be that I'm doing something stupid elsewhere, too).

If I were to do this incrementally, what's the best approach? Start with two. Output an image. Start again with that image and the next one. Output. And so on?

TIA.

[Terry Duell]

Hello John,

On Sat, 15 Nov 2014 11:15:23 +1100, John Muccigrosso <jmuc...@gmail.com>
wrote:

> I have about a dozen photos, overhead shots taken of an area. They don't
> cover all of it, so the final output is going to be a little weird
> looking.
> Hugin finds a lot of control points attaching the photos one to another,
> but the final output is very poor (in fact the fast preview shows the
> artifacts mentioned here

> <https://groups.google.com/forum/#!topic/hugin-ptx/64M28_sjxmo>).

>
> I started instead with just two photos and that stitch went fine, so I'm
> thinking it might just be simplest to work through the set incrementally
> (though it may be that I'm doing something stupid elsewhere, too).
>
> If I were to do this incrementally, what's the best approach? Start with
> two. Output an image. Start again with that image and the next one.
> Output. And so on?
>

There are a couple of approaches I would try.
The first would be to optimise all images in steps.
The second would be incrementally add images, using a minimal optimisation
at each step.
I guess it depends on how the project behaves as to which is the best
approach.
When it goes haywire in the Fast Preview window, have to checked to see if
it actually stitches OK?
Another approach is to see if you can find if any one image is the cause
of the problem and then look at the control points relating that image to
other overlapping images. You might be able to do this by using undo when
it goes haywire then deselect an image and repeat your last optimisation.
Also, try a different control point detector or different detector
settings to see if these help.
Let's know how you get on.

Cheers,
--
Regards,
Terry Duell

[Roger Broadie]

John Muccigrosso wrote on Fri, 14 Nov 2014 at 16:15:23 -0800 (PST)
-----

I have about a dozen photos, overhead shots taken of an area. They don't
cover all of it, so the final output is going to be a little weird
looking. Hugin finds a lot of control points attaching the photos one to
another, but the final output is very poor (in fact the fast preview
shows the artifacts mentioned here

<https://groups.google.com/forum/#!topic/hugin-ptx/64M28_sjxmo>).

I started instead with just two photos and that stitch went fine, so I'm
thinking it might just be simplest to work through the set incrementally
(though it may be that I'm doing something stupid elsewhere, too).

If I were to do this incrementally, what's the best approach? Start with
two. Output an image. Start again with that image and the next one.
Output. And so on?

TIA.

-----
For a photomosiac Hugin works fine for a few images (I'm assuming you
are working in translation mode) but does seem to get confused when
presented with too many images. Helping to steer the optimisation by
working incrementally does usually help in my experience. If you want
to work incrementally by images rather than by parameters for the whole
set you should not need to output a stitched panorama at each stage.
You can control which images are included by deselecting the rest in the
fast preview window and making sure that 'Only use control points
between images selected in the preview window' is selected in the
optimiser. When you have a satisfactory set, include those images in
the set selected in the preview window but switch off optimisation for
them so that the added images are then optimised with respect to the
original set. One advantage of this approach is that once the optimiser
has found a pretty good solution you should be able to improve it by
switching optimisation of the original set back on and reoptimising both
old and new images as a single set.

I have certainly encountered the sort of pattern shown in your screen
grab, which is the effect of extreme and absurd values in some
parameters. My first recourse is to revisit the control points, trying
to make sure they are spread right across all overlapping areas so that
the images are as interlocked as possible. That can be a rather boring
and time-consuming process. And usually adding horizontal and vertical
control points helps if there are features from which they can be
defined. But you may have problems if there are voids in your coverage.
It may help, at least as a first step, to locate the extreme parameter
values and reset them to 0 or a plausible value.

Roger Broadie

[John Muccigrosso]

Thanks for the help. I'll try these approaches.

Sometimes I've found that the stitch will work even when the Fast Preview is goofy like this, but not in this case.

Also the control points look good, which is why I'm surprised it doesn't work, even if the coverage is spotty.

These are overhead shots of trenches from different heights, so the surface isn't flat and there are all kinds of parallax issues. I need to optimize more than translation therefore (or so I believe). I'm just trying to get certain parts to look good, so I'm not concerned about perfection.

[Roger Broadie]

John Muccigrosso wrote on Sat, 15 Nov 2014 at 07:48:57 -0800 (PST)

-----

-----

I'm sure you will need to optimise the orientation parameters yaw, pitch
and roll, as well as the translation parameters X, Y and Z. But if the
ground is not at least approximately flat over the total area of
interest - it it includes varying slopes, for instance - you will be
working in circumstances to which the translation model does not,
strictly, apply and may well have difficulties. Whether there are any
advantages in trying to let the Translation plane yaw (Tpy) and
Translation plane pitch (Tpp) parameters vary as well to overcome that
problem I do not know: I have no experience of them.

Roger

[Terry Duell]

Hello John,

On Sun, 16 Nov 2014 02:48:57 +1100, John Muccigrosso <jmuc...@gmail.com>
wrote:


>

> These are overhead shots of trenches from different heights, so the
> surface isn't flat and there are all kinds of parallax issues. I need to
> optimize
> more than translation therefore (or so I believe). I'm just trying to get
> certain parts to look good, so I'm not concerned about perfection.
>

If your surface isn't flat and you are optimising for translation, if you
haven't already done so you will need to be placing your control points
manually to try to get them all on the same plane.

[John Muccigrosso]

Yes, that's my plan.