I am starting from the assumption that the two images are scans of the same original photograph, probably with the same scanner but with the controls set differently. Yo’av would be able to confirm if that is correct.
My conjecture is that the root of the problem is that the blotches that provide many of the control points are of different sizes because of the different apparent exposures, and probably also differ in shape, depending on the exact configuration of the standing stone where they fall.
I doubt if the best way of using Hugin is to rely on the presets that optimise position (which in this context actually means angular alignment) and other parameters, but not translation. That approach pins the optimisation to the central-viewpoint model that applies to a normal panorama but not to scans. As far as I can see, traditionally the central-viewpoint model has been finessed into working with scans either by relying on the d and e parameter that are designed to define shift of the sensor relative to the optical centre of the lens (as in Bruno Postle’s original version of the scanning tutorial, available e.g. here: http://web.archive.org/web/20080409195552/http://hugin.sourceforge.net/tutorials/scans/en.shtml) or by artificially setting the angle of view very small, to give the effect of a central-viewpoint camera at a great distance (which is the method recommended by the PTGui). But now, as Terry implied in his message of 02 Apr 2015 15:55:47 +1100 when he pointed to his revision of the scanning tutorial, we have the ability to use translation parameters X, Y and Z, which does directly what we want.
At this point I think I should offer a pto file. The one I have attached is based on Terry’s latest pto file, using its control points but resetting the parameter values to zero and then optimising just X, Y, Z and roll for just the second image. Its average control-point distance (at optimal size) is 3.2 and the maximum 6.0.
It seemed better to leave one image untouched (here image 0) rather than to allow parameters of both to vary. Frankly, I do not believe that the barrel/pincushion distortions of Terry’s images are more than artefacts of the optimiser, which if given enough parameters to play with can drive down the average error by juggling parameters. Any such distortion in the original photograph is irrelevant here and would be intolerable if introduced into scanned images.
I used only a single lens, since fov does not need to vary, differences in cropping being accommodated by changes in Z. I also eliminated a few control points by running the Clean control points function. Unfortunately, the preview (unless I'm missing something) does not combine the two images here. Image 0 masks image 1, which sits behind it, as can be seen by toggling the images on and off in the preview window. Thus the preview with both images enabled gives no clue as to the degree of alignment, although toggling the right images on and off in the preview window gives an impression of the degree of alignment.
This all may be more than Yo’av wants to know about Hugin and he may well wonder how he managed to get as good an alignment as he did based on the central-viewpoint model. I suspect the answer is that his alignment was so nearly right to start with that the values of yaw and pitch that Hugin determined were so small that they introduced little distortion.
Roger Broadie -- 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/552171BD.4010703%40ogea.freeserve.co.uk. For more options, visit https://groups.google.com/d/optout.
tld-apsc a.pto
Description: application/ptoptimizer-script
