Re. the colours in PTGui, what are you feeding it? Best practice is tiffs.

I fed it the full RAW files from the Sony . That was a question I forgot to ask on the previous post so thanks for answering it. Is it advisable to do much by way of capture sharpening, chromatic aberration correction etc before producing the TIFFs? I'm going to try and find some homework in this area now.

With regard to the power cables, I saw those errors. I think the building is OK in this version, but I'll double check tomorrow. The earlier version that used 5 images had a pretty bad seam between image 4 and 5. I actually removed some of the control points from the power cables. They were among the worst in terms of the distance and I didn't want to encourage the software to try to incorporate them correctly, so I moved those points back to places on the facade.

I haven't tried to stitch the 14mm version yet. Perhaps I'll give it a go in the morning. Yes, I was turned off by the visible distortion and also by the fact that it is so hard to focus, even under magnification. It's a dirt cheap Samyang or something. If I can find a profile for it should I apply that profile before sending the images to PTGui?

Yes, you should sharpen and fix chromatic aberration before stitching. But you should not attempt to fix any lens distortions - that will confuse PTGui. Vignetting? It's best to leave that to PTGui too. All the component images should have the same colour and tonal corrections applied. Best to go for a conservative treatment - you can punch it up on the final stitch.

Yes, you should remove ALL control points from the power cables.

Re. the 14mm Samyang. Don't apply any profile to it. When PTGui applies its control points, it is making a complex and accurate calculation of a lens's distortion characteristics. When it performs the stitch, all lens distortions are corrected for.

AFAIK, the raw conversion engine in PTGui is rather basic. It's best to convert the raw files first and then feed the resulting tiffs into PTGui.

Re. lens faults. PTGui allows lesser lenses to be used to good effect. This is because (1) it corrects lens distortions very well, and (2) in a stitch you are only using the good part of the lens (i.e. the edges are being cut off in the stitching process). That said, I still prefer to use really good prime lenses.

AFAIK, the raw conversion engine in PTGui is rather basic. It's best to convert the raw files first and then feed the resulting tiffs into PTGui.

I agree. I typically only correct for tonality and Color Balance, Chromatic Aberration, and do the bare minimum of Capture Sharpening in my Raw Converter of choice, full image, no cropping. I then save/export as a 16-bit/channel TIFF with the required color-space assigned (e.g. Adobe RGB or ProPhoto RGB). No distortion corrections needed, because those will be eliminated in the stitching process. The resulting Pano will have the source images' Colorspace assigned.

BTW The distortion correction parameters that PTGUI finds by analyzing overlapping images with lots of detail, can also be used to correct a single image. It will even allow adjusting for small amounts of decentering that almost every lens has. That's a great help for special lenses or lenses with mediocre distortion by the Raw converter application. Decentering is obviously rotation dependent, so take notes of the Vertical and Horizontal shift parameters (in the global Optimization parameters in Advanced mode) and the image orientation (e.g. rotation 90 degrees Clockwise).

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?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 So this looks like it's going to work.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 levelled? Yaw is lateral horizontality? Pitch is fore/aft horizontality? Roll is??So my last conundrum is whether to bother with the hire of the 11-24.

I didn't spend as long on this but here's the stitch of the wobbly 14mm. Seems if I move the panorama down to fit more sky (the only benefit of using the 14mm I think) then I lose the geometry of the building a bit. Not sure why this is happening.These are just screenshots from PTGui and I realise some of that (all of that) could be corrected in PS.Also, sharpness is not quite the equal of the 17, so I think I'm going to go with a 3 shot stitch of the almost fully shifted 17mm.

You could also try a "normal" pan with the 17mm as you did with the 14mm, shooting wider to get the 3:2 your customer wanted and a sharper image than the 14mm. Or at least take both and compare them ...

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.

Quote

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...

Quote

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.

Quote

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.

Quote

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.

Here's the latest attempt after purchasing the software license and using TIFF files rather than the RAW.

Hi Jon,

You're moving in the right direction.

Disregard the slight parallax errors in the lines in the foreground, that's possibly caused by them moving in the wind anyway. Only place control points on the building.

You can get rid of the lines/ribbons when you shoot the same panorama again, after raising or lowering the camera enough to clear the details that are now obscured. Then, either in PTGUI mask out the lines and ribbons, or later in Photoshop Mask and clone in the details from two images.

Thanks for the detailed notes Bart. I've copied them to Evernote so I can refer to them when I'm doing the work later and in the future. Going to re-shoot the building in early light over the weekend and will be working on the file next week.

Ok, shoot on the weekend went as well as can be expected (for working at 6am on a Sunday)Conditions were good etc.I tried to make sure that the rail was very level but PTGui reports for pitch & roll as before. Maybe that is as good as you get with a spirit level and a headlamp. I shot pretty much continuously from a point where sky lightened enough to get an exposure similar to the building artificial lighting until the open sunlight broke through too powerfully. During this time I show sequences of images from left to right, then I lowered the tripod head slightly using the central column and shot another sequence from right to left. I did this to get some images of 'behind' the powerless that were close to the camera.

A few things I need to ask:If I include both the sequences in PTGui it creates a poor quality stitch, with visible errors, and reports that control point pairs have distances of hundreds (of pixels?) between them.If I just use the one level sequence of images the result is much better, and the optimiser reports 'good' or 'very good'. So my strategy was to produce 2 panoramas and use the one from the slightly lower viewpoint as source material for the retouching job to remove the powerlines.So now some questions. Is it my task as a user of PTGui to manually manipulate the positions of control point pairs to reduce the distance between them? Does this action result in a better quality stitch? The help page says "A lower value means better alignment."If PTGui knows the distance between control point pairs why doesn't it automagically fix them?

I used about 8.5mm of vertical shift on the TS 17mm lens. According to Bart's previous post;"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."So let say 9mm. 9mm over 36mm (sensor size in that direction) is 25%, of 7952 pixels on the sensor is 1988 pixels of vertical shift. I'm on a different computer now but I think PTGui was reporting about 20% of vertical shift and a tiny negative amount of lateral shift in the lens parameters panel.So Bart, in order to follow your instructions do I uncheck everything in the lens parameters panel except the vertical and then run the optimiser again?The stitch as it stands is without errors that I can see, and while I'm confident of getting a result that the client would accept I'm treating this as a learning opportunity.There is noticeable softening of edges on the building as you move away from the centreline. I'm currently working on a full resolution panorama output by PTGui and haven't applied any sharpening. So that's about the only obvious improvement I'd like to see at this stage (and it will no doubt improve with some sharpening and downscaling later).I didn't do any meaningful screenshots today so there are no pics to go with this post.

Ok, shoot on the weekend went as well as can be expected (for working at 6am on a Sunday)Conditions were good etc.I tried to make sure that the rail was very level but PTGui reports for pitch & roll as before. Maybe that is as good as you get with a spirit level and a headlamp. I shot pretty much continuously from a point where sky lightened enough to get an exposure similar to the building artificial lighting until the open sunlight broke through too powerfully. During this time I show sequences of images from left to right, then I lowered the tripod head slightly using the central column and shot another sequence from right to left. I did this to get some images of 'behind' the powerless that were close to the camera.

A few things I need to ask:If I include both the sequences in PTGui it creates a poor quality stitch, with visible errors, and reports that control point pairs have distances of hundreds (of pixels?) between them.If I just use the one level sequence of images the result is much better, and the optimiser reports 'good' or 'very good'. So my strategy was to produce 2 panoramas and use the one from the slightly lower viewpoint as source material for the retouching job to remove the powerlines.

While it can be done in PTGUI, that would require some more work and experience with the application. The benefit would be that a single project file will allow to handle everything, without the need for retouching with an additional Layer-aware photoeditor. Let's save that exercise for a later date. For now, just make two panoramas, one for each of the slightly different shooting heights, and clone/heal the obstructions away between the two layered panoramas in e.g. Photoshop or similar.

Quote

So now some questions. Is it my task as a user of PTGui to manually manipulate the positions of control point pairs to reduce the distance between them? Does this action result in a better quality stitch? The help page says "A lower value means better alignment."If PTGui knows the distance between control point pairs why doesn't it automagically fix them?

In relatively easy cases, e.g. well-chosen no-parallax point, no moving subjects, steady tripod, and clear high contrast subject details, PTGUI will do a good job in finding the control-points in the image tile overlaps, with a good spread. That will result in an optimization with low residual control-point offsets. PTGUI will also add a text qualification indicating to how good it thinks the stitch will be (e.g. good or very good). But software can be fooled by it picking some wrong control_points (which will have higher error distances).

Then the software will have to find a compromise in combining all the required distortions (positioning errors of the no-parallax point, focal length deviations (and focus distance), lens distortions, lens decentering and/or deliberate shift, rotations, leveling, etc., all in three dimensions). As I said earlier, that's an "ill-posed math problem", but PTGUI guesses the most likely optimum, but still a compromise. In theory, one could add a control-point warping function, but that could lead to local distortions when there might be a better solution that will improve the overall result.

One thing one could do is look at the control-point errors and revisit the ones with the highest residual error. One can also let PTGUI automatically decide to remove the worst scoring ones. Then re-optimize and see if the average and maximum resulting errors are lower or not.

Quote

I used about 8.5mm of vertical shift on the TS 17mm lens. [...]So let say 9mm. 9mm over 36mm (sensor size in that direction) is 25%, of 7952 pixels on the sensor is 1988 pixels of vertical shift. I'm on a different computer now but I think PTGui was reporting about 20% of vertical shift and a tiny negative amount of lateral shift in the lens parameters panel.So Bart, in order to follow your instructions do I uncheck everything in the lens parameters panel except the vertical and then run the optimiser again?

PTGUI (Pro) version 11, which was released a month ago as successor to version 10, by default already optimizes for decentering/shift. So, if it automatically found an amount of shift that's in the order of what was to be expected, I would not worry too much about improving that, assuming that the resulting stitching looks fine.

Quote

The stitch as it stands is without errors that I can see, and while I'm confident of getting a result that the client would accept I'm treating this as a learning opportunity.There is noticeable softening of edges on the building as you move away from the centreline. I'm currently working on a full resolution panorama output by PTGui and haven't applied any sharpening. So that's about the only obvious improvement I'd like to see at this stage (and it will no doubt improve with some sharpening and downscaling later).

Hard to judge without an example, but it might be the inevitable result of the significant stretching that such a wide angle shot requires towards the edges/corners to keep straight lines straight. I wouldn't be surprised if the final panorama has a composited field of view that approaches 110 degrees horizontal FoV, or perhaps even more. The only way to increase edge resolution is by using a longer focal length (and many more tiles), so that there is the additional optical detail to work with. Of course, the larger the final stitch is, the more likely one can down-sample to the final output size, and that will also improve resolution (and PTGUI offers a selection of excellent resampling methods).

Thanks again for your reply Bart.Just to clarify. In attempting to optimise the control points I moved the points until the distance number reduced and in doing so I was more focussed on reducing the numbers than whether or not the control points occupied the same areas of the image. Should I instead move the control points until they appear to be over the same pixel(s) regardless of the distance numbers reported?

And also to clarify that by the time I had started this thread PTGui V11 was out, so that was what I had purchased and it was detecting the shift all by itself quite accurately. In the end I didn't change any of the lens parameters.

Anyway, it's been an interesting learning curve for me, and I should do some more practise with stitching and panoramas.

Attached shows where the file is at now. Doubt I'll spend much more time on it. There is a budget for this shoot. The warped appearance of the cars bugs me a bit but I think correcting that is beyond my abilities and time at the moment.

Thanks again for your reply Bart.Just to clarify. In attempting to optimise the control points I moved the points until the distance number reduced and in doing so I was more focussed on reducing the numbers than whether or not the control points occupied the same areas of the image. Should I instead move the control points until they appear to be over the same pixel(s) regardless of the distance numbers reported?

The latter, make sure that the control_points are on the exact same spot in the image tiles despite differences in distortion.

Quote

And also to clarify that by the time I had started this thread PTGui V11 was out, so that was what I had purchased and it was detecting the shift all by itself quite accurately. In the end I didn't change any of the lens parameters.

Yes, last month Version 11 became the current stable version. Unlike it's predecessor, Version 11 by default does include the shift parameters.

Quote

Anyway, it's been an interesting learning curve for me, and I should do some more practise with stitching and panoramas.

Attached shows where the file is at now. Doubt I'll spend much more time on it. There is a budget for this shoot. The warped appearance of the cars bugs me a bit but I think correcting that is beyond my abilities and time at the moment.

The warping of the cars is virtually inevitable, due to the extremely short shooting distance for this wide a FoV. When the output is viewed from the correct (very close) distance, there is no distortion. The apparent distortion is caused by viewing from too close up.