Hugin - mosaicing arbitrary images of differing width/depth
paul womack
of photographs taken from a single camera.
One of the consequences of this is that (as far as I can tell by experiment)
pixel width and depth is a property of the LENS not the image.
I was recently working on tessalating up a series of cropped screen grabs.
IMPORTANT
In order to make things work, I had to give each file a separate lens.
IMPORTANT
Interestingly, when optimising this mosaic, I then had a fairly free choice
between optimising FOV or Z. Both work...
In the interests of consistency with the several "real" photographic
mosaics I have I chose to give all the lenses the same FOV, and then
optimise Z.
BugBear
Roger Broadie
Paul Womak wrote on Mon 18 Jan 2016 at 09:50:10
-------------------
-------------
Paul, thanks for that helpful post. As we’ve seen in the past, the sort of thing you’ve been doing with photomosaics is much along the lines I have, which has including some stitching of images captured from websites where it has been necessary to zoom in and then shift the image between captures in order to get a useful resolution. Up to now I’ve always taken care to try to crop such captured images to a constant size. But I’ve done a quick check on a map of one area of interest to me, by taking care to crop the individual captures by different amounts and then stitching them with Hugin, to see how practicable it is to dispense with that requirement. It certainly seems that it is.
Yours is a very special case – effectively equivalent to stitching the output from a flat-bed scanner. One would then expect that all that is needed is the ability to shift the original images so they overlap correctly with their neighbours. That suggests that, if you start from a position where all the parameters are zeroed, then (ignoring fov for the moment) the only parameters that need optimising are X and Y, with the values for one image set at say 0 as an anchor. There shouldn’t be any roll or tilt that needs correcting. Since we are not using the central-viewpoint model, there doesn’t seem to be any need to be especially careful about the fov, which is important in the central-viewpoint model in affecting how the remapped images are wrapped around the panosphere. In my experience, for these flat stitches, just about any value does.
However, I'm sure you are right in general about fov and Z. They both affect the sizes of the remapped images, and in the same sense. Increase either and the footprint of the image concerned in the stitched image is increased. What I have found is that, if both can vary, repeated optimisation can lead,to the two parameters being pushed in opposite directions, with one increasing and the other decreasing so as to keep the footprint roughly constant in size. Thomas Modes's good advice was to optimise only one of the pair (see his comments on Fri, 3 Oct 2014 at 01:08:33 -0700 (PDT)). That of course is what you are doing by fixing the fov value(s) and optimising Z for the individual images.
When I loaded the images that had been cropped to varying sizes, Hugin decided to give them individual lenses. I gave each an fov of 40 (a purely arbitrary value) and left all the other parameters at 0. Then I optimised X, Y and – to accommodate the varying image widths – Z. That gave a very good optimisation. The pto file and screen grabs of the Fast Preview window and Optimiser tab are attached.
Of course one then wonders if the lenses can be combined into one, since they undergo no changes under optimisation and the parameters are identical. In fact they cannot. As you pointed out, using individual lenses is essential in Hugin when cropping to non-constant dimensions. Your characterisation is that “the pixel width and depth is a property of the LENS not the image”. I would rather put it like this: Hugin assumes that all the images for a given lens have the same dimensions. The way it works is most likely this. Left to itself it will give a separate lens to each image of a different size. If you override its determination and group several images of different sizes under the same lens it will conclude you know what you are doing and give all those images the same dimensions, probably those of the first image of that lens it meets. There is then a conflict between the assumed and actual dimensions that defeats both the preview window and the stitcher, though not the optimiser. The stitcher fails with the message “Precondition violation! …. image sizes not consistent”.
I’m not sure why Hugin acts in this way, but it is not absolutely necessary, as is shown by the fact that I loaded the same images into PTGui Pro and applied the nearest thing to the same optimisation process and it gave a very similar result to Hugin without needing to give each image its own lens (in the sense of allowing individual optimisation of the lens parameters per image). Specifically, I gave the single lens an fov of 40 and optimised only viewpoint correction for all images except one, which was left with all at 0 as an anchor. Even so, it retained the information about the dimensions of each image.
Nonetheless, whichever stitcher you use, it does seem possible to use cropped screen grabs that do not all have the same dimensions, which eliminates some of the effort necessary in assembling a stitch from this type of source. That’s really useful to know.
Roger Broadie
