Mosaic mode - numerical effect of parallax

[paul womack]

I was wondering how big the errors introduced by
3D features in the assumed 2D target plane were.

So I made the attached diagram.

It appears "obvious" that, assuming the whole FOV is 'R'
pixels (resolution), that the error is a simple proportion,
since the triangle "projected" by the feature
is similar to the FOV triangle of the camera.

Thus; error (in pixels) = (v/L) * R.

This is independent of FOV, which is interesting.

So, for "perfection" (less than 1 pixel error) with my
8 M Pixel camera, (3264 horizontal pixels), from a shooting distance of 24" (600mm)

1 = v/600 * 3264

v= 600/3264
= 0.2 mm.

Wowza, I wasn't expecting *that*.

Conversely, if we assume a 3mm wrinkle
in the target;

1 = 3/L * 3264

L= 3 * 3264 = 9792mm

I would need to be 10 metres away to get the error out.

Practical conclusion; I need a means to deal with these
errors in post processing, since it is not reasonable
to eliminate them at shooting time.

BugBear

[bugbear]

paul womack wrote:

>
> Practical conclusion; I need a means to deal with these
> errors in post processing, since it is not reasonable
> to eliminate them at shooting time.

If only there were some way to map-out localised
parallax errors. :-)

http://www.bruno.postle.net/2012/ptomorph/

Announced to the list:
https://groups.google.com/forum/#!topic/hugin-ptx/UripOuuYXCQ

This is IDEAL for my purpose.

However, when using this ALL control points
must be "good", in that they truly indicate
corresponding visual entities on the images.

Whereas for Panotools, the effect of all the CPs
are averaged into a small number of transform parameters;
for ptomorph, each and every CP is acted on fairly directly.

I suspect this means:

"manual CPs only"

I am discovering that you also need a LOT of CPs for ptomorph
to give a truly perfect result for localised bumps.

BugBear

[bugbear]

OK. Ptomorph has a tiny bug in its path handling.

it uses the same path prefix for its output files
as its PTO file.

The upshot is, the path must be either absolute, or current.
I'm creating my morphs in a sub-directory (snapily called morph).

but:
ptomorph -o ./morph/morph.pto orig.pto

doesn't work, because the resulting morph.pto contains
references to morph/morph_0000.png (etc).

I have to (in Unix);

( cd morph; ptomorph -o morph.pto ../manual4morph.pto )

which works nicely.

BugBear

[Bruno Postle]

On 1 June 2015 13:15:59 BST, bugbear wrote:
>OK. Ptomorph has a tiny bug in its path handling.
>
>it uses the same path prefix for its output files
>as its PTO file.
>
>The upshot is, the path must be either absolute, or current.
>I'm creating my morphs in a sub-directory (snapily called morph).

Oops, yes this needs fixing, the paths in the PTO file should be absolute or relative to the folder the PTO file is in.

--
Bruno

[Donald Johnston]

Does anyone know if there is a documented procedure on how to install/run panotools on Mac OS x?

[Bruno Postle]

Thanks for the bug report, this should now be fixed in Mercurial.

Note that ptomorph could still use testing and feedback since it is
a prototype for possible future Hugin functionality.

By default it uses the 'Shepards' morph from ImageMagick, this is
very stable and forces _all_ control points to line up - I could see
this being integrated in the nona stitcher as a single option.
http://www.imagemagick.org/Usage/distorts/#shepards

ptomorph also has an option to approximate a fit for the whole image
with a 'polynomial' distortion - this is smoother, but isn't as
stable. It potentially could be integrated into the entire
panotools optimisation/remapping stack, but this would be a bad
idea if it isn't useful.
http://www.imagemagick.org/Usage/distorts/#polynomial

--
Bruno

[bugbear]

Bruno Postle wrote:
> On Mon 01-Jun-2015 at 23:59 +0100, Bruno Postle wrote:
>> On 1 June 2015 13:15:59 BST, bugbear wrote:
>>> OK. Ptomorph has a tiny bug in its path handling.
>>>
>>> it uses the same path prefix for its output files
>>> as its PTO file.
>>>
>>> The upshot is, the path must be either absolute, or current.
>>> I'm creating my morphs in a sub-directory (snapily called morph).
>>
>> Oops, yes this needs fixing, the paths in the PTO file should be absolute or relative to the folder the PTO file is in.
>
> Thanks for the bug report, this should now be fixed in Mercurial.
> Note that ptomorph could still use testing and feedback since it is a prototype for possible future Hugin functionality.

Yes - so far I have found that "it works", but for resolving the particular effects
of creased/wrinkled maps I need a VERY large number of CPs. This may simply
speak of the complexity of my creases, and that "simpler" creases would
require less CPs.

And these CPs, by the very nature and need cannot be optimised by Hugin.
So you really need two classes of CP which hugin doesn't support.

At the moment, while experimenting, I have to set the "stitch" CPs,
optimise, and then NEVER OPTIMISE again.

I then add lots of "morph" CPs, (which by their very nature
are placed on points that show high errors) and use ptomorph, nona.

> By default it uses the 'Shepards' morph from ImageMagick, this is very stable and forces _all_ control points to line up - I could see this being integrated in the nona stitcher as a single option. http://www.imagemagick.org/Usage/distorts/#shepards
>
> ptomorph also has an option to approximate a fit for the whole image with a 'polynomial' distortion - this is smoother, but isn't as stable. It potentially could be integrated into the entire panotools optimisation/remapping stack, but this would be a bad idea if it isn't useful. http://www.imagemagick.org/Usage/distorts/#polynomial

BTW, Nona is dramatically faster!

BugBear