Control Point Bias

[Michael Perry]

Is there not a bias in the way Hugin optimises; that control points at the intersection of four images will be weighted three more times than those at the intersection of the pair of images above or below? The larger error in control points always tend to be the furthest from the centre.

Without manually adding control points away from the 4-way intersection (or removing those in the centre), is there some way to compensate for this with cpfind or autooptimiser?

(Hoping the attached image posts)

[Florian Königstein]

Since every control point connects only two images, it's normal and reasonable that you have more CPs in the intersection of 4 images. Every CP generates constraints on the relative position of two images.

In Hugin++ you could set weights for control points. However, this should in most cases only be necessary when you have "good" CPs and "bad" CPs (e.g. due to moving objects) and you have no other choice but keeping some of the "bad" CPs. Then you can assign higher weights for good CPs and/or lower weights for bad CPs.

[Michael Perry]

Thank you Florian; I can see a logic in your statement. However, I still think there is something odd with this. It may be a particular result of working with mosaic stitching in very controlled conditions; the images making up my panoramas are laid out on a regular grid and my control points are often repeated between multiple images.

 My "errors" always tend to be the control points towards the edges, those which are only in two images. My best CPs are always those towards the centre of any four images. This is because, I believe, the optimisation prioritises points equally across the panorama/mosaic. However, if one set of points is repeated many times, the model will tend to exaggerate the correctness of those points over the equally important points at the edge.

I think your weighting feature in Hugin++ could be very helpful.

[Gunter Königsmann]

Two possible reasons I can think of: If you place 100 control points very near to each other they will count more than a few control points at the edges caused by their sheer number.

...and if the lens distortion isn't modeled accurately for your lens there is a high probability that the middle of the lens can be matched better than the edges of the viewport.

[Florian Königstein]

If you set the weight of a control point to a value W, the geometrical optimizer treats it like if there were instead W control points at the same position (if W in an integer). However W needs not to integer. If no weight is given, a weight of 1 is assumed.

If for some reason the stitching yields visible striking errors at a position, you could force the error to get smaller by increasing the weights of CPs near this position. However, the errors at other positions will increase more or less. If you unfortunately increase the weight of a CP that is bad positioned (on moving objects or due to not corrected errors from lens distortion) this will lead to much more visual defects at other positions. So you could e.g. set the weight set to 4 in order to make the error smaller at this position, but setting it to 100 could be problematic.

I have a large panorama where I took the photos with a relative small angle of view (tele photo). On some CPs on the trunk of a tree I set the weight to 100, but on some photos are only small branches or leafs of trees, and these CP have weights of 1. On some photos I didn't have another choice but using CPs on clouds, and I set their weights smaller than 1, e.g. 0.1.

[Klaus Foehl]

Hello Gunter

> better than the edges of the viewport. --

I've got several cameras with even more lenses, and your "high
probability" is a slight understatement. I run enblend with --visualize
and inspect the vis files after each stitch. Switching on the
mathematically challenged parameters a and c sometimes make things
really worse.

Usually I use b, d and e. With 360° one needs also v. With good image
material the average deviations as indicated in the optimiser are 1/2
pixel. Compare this to 1/10 pixel from Finetune, my finding from a few
years ago.

"lens distortion isn't modeled accurately" - please include more of
Brown-Conrady into hugin - or hugin++

Best regards

Klaus

P.S. Of course some lenses underperform in the corners, and the issue of
mechanical vignetting may come up which requires maths beyond
Brown-Conrady to model.