On 20 August 2019 09:53:54 BST, Vegard Brenna wrote:
>
>So far, I'm only concerned by getting something that looks decent in
>the Fast Preview window.
>cpfind and cpfind + celeste produce identical, unusable results. I
>thought perhaps celeste could remove uncertainty caused by uniformly
>painted walls, but no.
Celeste only removes control points from things that look like fluffy clouds,
it was trained on a collection of sky photos.
>Accepting Pic #0 as Anchor or moving the Anchor to #1 produce identical
>results.
This is expected, the 'anchor' image is the photo that doesn't move around the
canvas during optimisation, it is not involved in control point generation.
>Performing Edit>Fine-tune all Points (discouraged by T Modes) has a
>significant effect:
>Deleting Correlation < 0.80 transforms the Preview from "a stack of
>cards" to something that resembles what I'm after. But still useless.
>Deleting Correlaton < 0.90, 0.95 results in a steadily decreasing
>quality of the Preview, with larger and larger mismatch.
This sounds like you have ended up with too few control points to control the
optimisation properly.
Manually fixing control points is not so hard: display the Control Points
table, sort by 'distance', and click on the points with the largest error
distance one at a time, you can easily see which points need to be deleted or
repositioned.
I suspect that you have multiple problems caused by the pre-processing you are
applying to these photos:
The processed photos have different pixel sizes, this is preventing Hugin from
linking lens parameters during optimisation.
Tone mapped images are radically changed at a local scale, it is possible that
they are no longer similar enough for cpfind. Hugin likes photos as they come
from the camera.
Hugin is capable of stacking bracketed photos and generating HDR or
exposure-fused output during the normal panorama stitching process. This might
give better results than pre-processing the stacks.
In any case you should test stitching photos from just one exposure level of
your bracketed suits to establish that this is or isn't the problem.
>My guess is that since I always give my image files a prefix Px_ so
>that they correspond to the rows in the matrix like this ...
>P3 P4 P5
>P0 P1 P2
>... then Hugin "gets it" and processes them in the correct order.
The filenames will affect the order that the photos initially appear in the
project, but are otherwise ignored by the control point generation process.
--
Bruno
--
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 [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/hugin-ptx/B4064680-FDF4-4B25-A1C7-310B4E6F3928%40postle.net.
