Here's the latest attempt after purchasing the software license and using TIFF files rather than the RAW. This is with the shifted 17mm. It seems PTGui can detect the lens has been shifted so unless I'm wrong there's nothing to do there Bart?
Hi Jon,
Let me share a little tip that is overlooked by many.
While PTGUI is able to detect many sources of geometric distortion in our image tiles, it also makes it a more challenging task for the software to do it all automatically. The software challenge is known as an "ill-posed math problem", because there are multiple solutions that can reach a mathematical optimum. But only a few of those solutions make sense to a human observer, and only one is really optimal.
The more parameters we select to be optimized at the same time, the harder the challenge. For that reason, the Vertical and Horizontal shift parameters are usually disabled when finding an optimal solution.
My solution is to disable (!) all other optimization parameters, and let the software seek for a solution for only Vertical displacement. If you know how much shift you used when shooting, you can enter the values manually. In PTGUI version 10, one can calculate the amount to enter by taking the mm of shift, divided by the total tile height in mm, multiplied by the total number of pixels of the tile in the vertical dimension. If you run the detection automatically, verify that it approximately finds the same number of pixels you calculate by hand.
Once you have a decent approximation of the Vertical shift in pixels, now disable this parameter for the subsequent optimizations. Once you've reached a new optimum, you can again try only optimizing for the Vertical shift once more, and see if it changes much.
Also make sure that you only apply this optimization for the Row(s) of tiles that had shift involved.
This all will make sure that all the other geometrical aberrations, which are rather symmetrical around the real optical center of the cropped image circle, can be compensated to achieve the maximum accuracy.
Even on unshifted images, I usually follow up on a regular optimization, by one run of
only Vertical shift, and one run of
only Horizontal shift. If the resulting shift amounts are small, they probably will improve a subsequent general optimization with even smaller residuals. I often get only sub-pixel residuals for most of the control-points.
It's this level of control that only dedicated stitching applications can offer.
I also do a rigorous inspection of which (automatic) control-points are used. Always making sure that the main subject structure is well covered, and nothing that moves (such as trees, or plants, or cars, or people, or clouds, or even birds/insects). I may be a bit obsessive about that, going through
all possible image pair overlaps, but you only have to do it once and it will help the final result/quality.
I used some vertical control lines in this version after learning about them last night. Yet to do horizontal ones but the tutorial I read seemed to say that PTGui would work out the horizontal stuff.
Yes, your test run showed lots of reliable corners and lines on which to place these additional control points. Some architecture may be deceiving with slightly receding or protruding elements that hide true verticals and horizontals, but your example looks 'straightforward'.
Another tip, one can also use Horizontal and/or Vertical control points on single images or tiles. Just use the Controlpoints Tab and select the same image twice, clicking on one end of the line in one image pane, and the other end of the line in the other image pane.
And another tip, some architecture will look a lot better with a tiny amount of keystoning left in the image. This can be achieved by disabling all optimization parameters and manually adding a slight amount of Pitch to all images, then disabling the pitch optimization and running a general optimization.
Since the "ill-posed math problem" issue remains, the optimization engine can lose track in the midst of things, and a previously acceptable stitch can turn into something totally screwed up. So always save the intermediate result before experimenting with more optimizations. Just in case the undo function doesn't work...
So this looks like it's going to work.
I'm confident it will. It's just a bit of a learning curve to get the optimal result, but the application is a real workhorse. Also things that are under the hood, like much better interpolation algorithms than most image editors use, will result in higher output quality. Especially important with so much deliberate distortion and warping going on.
The example below is the preview from PTGui and hasn't had any subsequent P'shop work. The second attachment I presume shows me how well or otherwise my camera position was leveled? Yaw is lateral horizontality? Pitch is fore/aft horizontality? Roll is??
When shooting perpendicular to the front of the building, the Yaw (horizontal angle around the vertical axis through the entrance pupil or no-parallax-point), the Pitch (the up/down angle around the horizontal axis through the no-parallax-point), and the Roll (sideways rotation along the front/rear axis through the no-parallax-point), the lower the values for the center image tiles are, the more squared/perpendicular your lineup (after software adjustments) is.
However, do note that you can deliberately deviate from those values with a manual override for esthetical reasons. As mentioned, a slight amount of Pitch can help in reducing the mistaken suggestion of vertical stretching, and you can still add dynamism by manually overriding the Yaw angle, as if you were shooting a bit more from the side instead of head-on. Just modify how the image is cropped after manually overriding the optimization parameters.
So my last conundrum is whether to bother with the hire of the 11-24.
My experience tells me that when you get the hang of stitching, it hardly adds time when shooting, it only adds a bit of time in postprocessing, but with higher image quality. A wider angle lens may save time, but rarely improves image quality, unless it's an exceptinally good lens. Wider angles usually/inevitably will also result in more veiling glare that reduces image contrast and acuity. I even use my TS-E 24mm II for stitching, unshifted, and with a different/deeper lenshood for a 24mm lens, thus optimizing the use of the center of the image circle, and larger magnification than the 17mm version, and let the stitching software make a better leveling and keystone correction than I possibly can, even on a Manfrotto Geared head and an electronic level. The reason is that many sensors have a very tiny rotation that even the stitching software will have to compensate for.
Cheers,
Bart
P.S. Sorry to add to an already long message, but, buyers of the current PTGUI Pro version 10 License can also use the Beta version 11. While already quite stable, it is still a beta version. However, it has changed the Horizontal/Vertical shift in pixel amounts, to relative shifts for the Long/Short dimension of the image tiles. The benefit is that a mix of landscape and portrait orientation tiles can be intermingled in the same pano stitch. That's just one of the improvements, so make sure to check it out.