Map/transform questions and sample size?

[paul womack]

What's the list policy on attachments? I have taken
(at home, using a tripod) some photos of a map
I own, and prepared a hugin project.

The 5 images are all 3264x2448 (8 Mpixels)
and are around 3.5 Mb each.

3 of the images are a sequence where I only
moved the tripod along, and can be easily optimised
by setting the middle one as anchor, and optimsing
for Y/P/R and X Y.

The other two where taken with the tripod off to the left/right
sides of the map, which the camera tilted to look right/left
towards the centre of the map. These samples represent
"off axis" shots. I cannot get these to optimise;
I used "Only use control points between image selected in the preview window"
to try to just optimise the rightmost skew image (which looks left)
to the centre "straight on" image, but failed.

I also failed to get the left/right skew images to optimise to each
other.

Are the samples too big for the list?

I attached the (tiny!!!) project file in any case.

BugBear

[bugbear]

paul womack wrote:
>
> Are the samples too big for the list?
>
> I attached the (tiny!!!) project file in any case.

Hopefully this hightail link will work.

https://www.hightail.com/download/UlRUS3hjNnl5UkZjR01UQw?cid=tx-02002207340200000000&s=19102

BugBear

[Marius Loots]

Hallo Paul,

Wednesday, October 8, 2014, 11:55:55 AM, you wrote:
paul> I also failed to get the left/right skew images to optimise to each
paul> I attached the (tiny!!!) project file in any case.

My (very quick) attempt attached. There is still a problem on the Q
row, that could maybe be fixed. I used the following steps:
1. Loaded all images. Skew-left.jpg was the default for anchor and
exposure and I left it like that.
2. Didn't fiddle with camera and lens settings.
3. Created control points with CPFind + Celeste.
4. Went to preview panorama and deselected image 2, 3 and 4.
5. Optimised Positions (incremental, starting from anchor).
6. Went to preview panorama and added image 2.
7. Optimised Positions (incremental, starting from anchor).
8. Repeat for image 3 and 4.

Up till this point images were still bit wonky, but seems to be in the
correct place.

9. Then went to optimize all except anchor for Position and
Translation.
10. Optimize adding View, then Barrel and then Position, Translation,
View and Barrel.
11. Stitch.

I would suggest you see if you can't photograph the whole thing flat
and from a fixed point, rather than attempting to fix it afterwards. I
have had good success, even by moving and rotating the target, as long
as the camera stays at the same distance and perpendicular to the flat
surface.

Hope this helps.

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.

[bugbear]

Marius Loots wrote:
> Hallo Paul,
>
> Wednesday, October 8, 2014, 11:55:55 AM, you wrote:
> paul> I also failed to get the left/right skew images to optimise to each
> paul> I attached the (tiny!!!) project file in any case.
>
> My (very quick) attempt attached.

It's very impressive, and much better than anything I achieved
(which was frankly "not so much").

My control points were good though - all hand placed and checked ;-)

I will study what you did.

BugBear

[Roger Broadie]

paul womack wrote:
>>
>> Are the samples too big for the list?
>>
>>I attached the (tiny!!!) project file in any case.

>Hopefully this hightail link will work.

It certainly did.

I attach two files. The first (map1.pto) is a pto file for the complete
set, giving an end-result pretty much like Marius Loot's, but
illustrating the use of the workflow I sketched in my post of 1 October.
I used your control points, except that I corrected a couple of
erroneous points that showed up as anomalously large errors in the the
Control Points Table (cps 5 and 7 between images 1 and 4) and added
vertical and horizontal control points using the edges of the paper. I
also reoptimised the lens characteristics, though I'm not sure that
helped much.

There were some stitching flaws in the seam between images 1 and 2,
which I suppressed with an Include mask in image 2.

The final result is not brilliant if you are looking for sub-pixel
average errors, but I am not sure they are obtainable with photomosaics
of maps and the like that have been folded, as I think yours had been.
There are still a few small stitching flaws that would need massaging
away. But as a record of the original, with the folds perceptible in
the final image, it seems fine to me.

The failed stitch between images 1 and 4 from your pto file I resolved (
map i1+i4.pto) by leaving the parameters for image 1 as they were,
resetting all the values for image 4 to zero in the optimizer, deleting
cps 5 and 7 and progressively adding the following parameters for image
4 to the optimisation: (1) X and Y, (2) Z, (3) r, (4) y and p. That is,
I used the the basic workflow of my earlier post, reduced to the case of
two images. Your pto file illustrates the fact that a value of Z that
is more negative than -1 is a sure sign that the optimiser has failed,
presumably because of something to do with the way you fed it with
parameters.

Roger Broadie

[Roger Broadie]

On Wed, 8 Oct 2014 13:14:31 +0200 Marius Loots sent us his pto file to
stitch Bugbear's images (of a map of Norwich, I think).

I too was impressed by the quality of Marius's result. I wondered if it
was attributable to his workflow, or to his new set of control points.
I therefore generated a new set of my own and stitched that by the
method I have described (map 2.pto, attached). Now I can't find any
stitching glitches at all, though heaven knows they can suddenly catch
one's eye later, however well one thinks one has searched for them at
the time and found none. So I suppose the moral is the rather trite one
that you can use what workflow you feel comfortable with, but a good set
of control points is the rock on which the stitch is based.

Thanks to Paul for getting us thinking about this interesting topic. I
owe to his original posting in June my appreciation of the importance of
defining horizontal and vertical control points when stitching
photomosaics in Hugin.

Roger

[bugbear]

Roger Broadie wrote:
> I therefore generated a new set of my own and stitched that by the method I have described (map 2.pto, attached).
> Now I can't find any stitching glitches at all, though heaven knows they can suddenly catch one's eye later, however well
> one thinks one has searched for them at the time and found none. So I suppose the moral is the rather trite one that

For those wanted to REALLY check for glitches, it's easy to use a sort of
blink-test (c.f. http://en.wikipedia.org/wiki/Blink_comparator).

Simply make a multi layer tiff of your data, as per

http://hugin.sourceforge.net/docs/manual/Hugin_FAQ.html
> How can I postprocess the image using multiple layers in The Gimp?
>
> Use the nona stitcher on the command-line, to output to a multilayer TIFF format:
>
> nona -m TIFF_multilayer -o multi_layer.tif project.pto

Then load this into Gimp (hope you've got lots of RAM)
order the layers to your liking and just click on an "eyeball"
icon in the layer display to turn layers on and off. This can be done
at 1:1 display resolution, and any errors will (for better of worse)
leap out at you.

In the case at hand, I'm afraid there are errors, but I don't think Roger's
careful works is at fault; since the map has been folded, there are slight
hills and valleys in it. These cause genuine (if small) parallax errors
which hugin simply cannot resolve.

BugBear

[T. Modes]

Am Donnerstag, 9. Oktober 2014 15:54:30 UTC+2 schrieb bugbear:

For those wanted to REALLY check for glitches, it's easy to use a sort of
blink-test (c.f. http://en.wikipedia.org/wiki/Blink_comparator).

Simply make a multi layer tiff of your data, as per

Or much more simple, use the difference feature of one of the previews.

[bugbear]

T. Modes wrote:
>
>
> Am Donnerstag, 9. Oktober 2014 15:54:30 UTC+2 schrieb bugbear:
>
> For those wanted to REALLY check for glitches, it's easy to use a sort of

> blink-test (c.f. http://en.wikipedia.org/wiki/Blink_comparator <http://en.wikipedia.org/wiki/Blink_comparator>).

>
> Simply make a multi layer tiff of your data, as per
>
>
>
> Or much more simple, use the difference feature of one of the previews.

Much simpler, but MUCH lower resolution.

BugBear

[Roger Broadie]

BugBear wrote on Thu, 09 Oct 2014 1at 4:54:22 +0100 about the presence
of stitching glitches in photomosaics.

He pointed out that if the individual transformed images of the sample
photomosaic we were investigating (a map of the English cathedral city
of Norwich) were loaded in a stack errors were visible.

Actually, in my post of 8 October, by stitching glitches I merely meant
those that are visible in the final output.

Certainly there are mismatches in the remapped images where they
overlap, as is, I think, not unusual. But in theory, for any given
point, the stitcher should allow only one version of it through to the
final product and I can'’t see that differences between that version and
those from other images that are invisible in the final product are
directly relevant. In the map we have been looking at the stitcher has
been generally able to make a good choice and even where distortions are
visible it is clear that they originate from the remains of folds.

Nonetheless, the discrepancies between the different remapped images are
a reminder that the final photomosaic is not to be relied on as an
accurate scaled-down reproduction of the original, much though one would
like it to be.

Roger Broadie

[bugbear]

Roger Broadie wrote:
> BugBear wrote on Thu, 09 Oct 2014 1at 4:54:22 +0100 about the presence of stitching glitches in photomosaics.
>
> He pointed out that if the individual transformed images of the sample photomosaic we were investigating (a map of the English cathedral city of Norwich) were loaded in a stack errors were visible.
>
> Actually, in my post of 8 October, by stitching glitches I merely meant those that are visible in the final output.

Ah, agreed.

I use the multi-layer trick to check the optimisation. I am (as you imply) perfectly happy,
when the optimisation is as good as it can be, to use enblend to further reduce the visual consequences
of any optimisation errors.

>
> Certainly there are mismatches in the remapped images where they overlap, as is, I think, not unusual. But in theory, for any given point, the stitcher should allow only one version of it through to the final product and I can'’t see that differences between that version and those from other images that are invisible in the final product are directly relevant. In the map we have been looking at the stitcher has been generally able to make a good choice and even where distortions are visible it
> is clear that they originate from the remains of folds.
>
> Nonetheless, the discrepancies between the different remapped images are a reminder that the final photomosaic is not to be relied on as an accurate scaled-down reproduction of the original, much though one would like it to be.

Indeed.

BugBear