help for new user

[Jon Schewe]

I'm piecing together a family tree that I took photos of with the camera on my phone. I made sure to have some overlap across the images so that I could stitch them together later. Now that I'm doing that stitching I'm having a hard time getting a few of the images to line up correctly. 80% of them are correct, but a few are not. In one case 2 images are offset vertically from where they should be. In another case I'm getting duplicated data. In both cases I've found all of the overlapping images and added numerous control points between them. However that doesn't appear to fix things.

I'm sure this is user error as I'm very new to using Hugin. I've read through a few of the tutorials and for the most part things just work, but I'm not sure about the proper workflow for making these changes.

Currently I do the following:

1. add control points

2. click optimize

3. stitch

I then check the result and then repeat

Should I instead be using align instead of optimize? What's the difference between these two operations?

I have 34 images, should I start with just a couple and build up rather than loading all of them at once?

For the projection. I expect that the lens type should be rectlinear. 

For the output, I'm not sure what is best. Rectlinear doesn't appear to handle the wide image. Equirectangular appears better. I've also tried cylindrical, which handles the size, but curves the lines.

An oddity I've noticed is that the GL preview turns into a blank window for me when making changes. I need to change the interface view and then it shows up.

A minor oddity is that my PNG output files have a PNG offset. When opening in Gimp I get prompted for what to do with this. If I ignore it, the final image is visible, if I use it the image is shifted to one side and much of the image is missing. 

I'm using Hugin version: 2019.2.0.b690aa0334b5 on Ubuntu Linux. I've also tried version 2020.0.0.2f576e5d5b4a installed via Flatpak.

Any and all help is greatly appreciated. If it helps, I can post the images and some of the results on my website.

Jon

[johnfi...@gmail.com]

I was really struggling to accomplish anything with Hugin, before I realized the "Simple" interface is harder to use than the "expert".  Maybe "Simple" is OK if you did a great job with your tripod making sure every photo is from the same axis point.  But I expect you did not.

In the photos tab, you need a good choice for "Geometric".  If you didn't do a great job keeping the axis stable, you need to include "translation" (x,y, and z).  If you want control points near the corner of any photo to do more good than harm, I think you need to include view and Barrel (I'm less clear on that, more reporting experience with partial understanding of the theory).

I never got the preview to be worth the trouble.  It is very hard to get a properly positioned and zoomed image and then the preview isn't accurate enough anyway (maybe others can give a better answer to that aspect).

I reviewed control points and improved on the choices made automatically.  Assuming the "translation" choice was really needed then between photos that need translation, control points at multiple distances do more harm than good.  I changed the selection of control points so they were all on the edges of objects that were about the same distance from the camera (get rid of all auto selected control points deep in background).

You may want to try experimenting with fewer images to get used to the tool.  When you want to assemble a lot, I'm still learning myself what the best approach is.

[Jon Schewe]

Thanks for the suggestions. 

I tried setting "Geometric" to "Custom Parameters" and then in the Optimizer tab selected x, y, z and barrel (in the lens settings). Then I clicked optimize and all of the images ended up on top of each other. So that didn't work so well.

As far as control points, I have been working under the assumption that more is better. In this case all of my images are hand writing on sheets of paper, so I'm putting all of my control points on corners of characters. Any control points not on characters I've been removing.

Using the 2020 version, the zoom with the mouse in the preview is working reasonably well. Although the preview still disappears on me regularly.

--
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 hugin-ptx+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/9e52d0be-baa7-443c-9acf-f6a77e6b5aa7n%40googlegroups.com.

[johnfi...@gmail.com]

I suspect there are some very wrong control points involved in getting all the images on top of each other.

I'm not convinced more is better.  More increases the chance of failing to notice some very bad ones.

Handwriting on a sheet of paper should eliminate the problem of multiple control points in the same photo being significantly different distance from the camera.

Did you take the photos with a tripod and a carefully controlled axis of rotation (near the point at which the viewing angle converges)?  If so, then the x,y,z aren't really needed.  But for taking a photo of a large sheet of paper, I expect you didn't have that controlled axis of rotation, so x,y,z are really needed.

Still sounds like you need to experiment with part of the intended panorama in order to find out what is going wrong.

[Jon Schewe]

I did not use a tripod. I just tried my best to keep my hands steady with my cell phone. I've started a new project with just 2 of the images that I'm having a very hard time lining up. I'm finding that they were taken at different distances from the paper, so to line things up one image needs to be stretched to match the other one. Does Hugin support doing that? If so, which Geometric parameters need to be adjusted? I see that y,p,r are listed next to "position". When I think of position I think of x,y,z on a coordinate plan. 

Is there a good reference for what the following terms mean to Hugin?

Position

View

Translation

Barrel

BTW I found a reliable way to fix the preview window, if I press F11 I can get the preview back when it's disappeared.

[Bruno Postle]

On Sun, 26 Dec 2021, 23:57 Jon Schewe, wrote:

Is there a good reference for what the following terms mean to Hugin?

Position

View

Translation

Barrel

Position is roll, pitch and yaw.

View is the horizontal lens angle of view.

Translation is xyz position of the camera.

Barrel is the radial barrel (or pincushion) distortion of the lens.

For your document assembly project, you will need to use all of these, but not all at once - this can confuse the optimiser. I suggest starting with translation, then adding position, then view and finally add barrel.

-- 

Bruno

[Jon Schewe]

That helps, let me restate to make sure I understand.

Position refers to how the camera is rotated relative to the paper. So assuming the center of the camera is always at the center of each image and the distance to the image is the same, this corrects for how the camera may have rotated around a point.

View seems like it would be also covered by the position if using the same camera for all images. Am I correct?

Translation is how the center of the camera has changed relative to the center of the image. Am I correct that x and y are left/right and up/down and z is the distance the camera is from the object?

Barrel fixes straight lines being curved.

I did find that telling Hugin to use separate lenses for each of the 2 images helps quite a bit. 

I stumbled upon this tutorial that suggested using 2 lenses http://hugin.sourceforge.net/tutorials/scans/en.shtml

Jon

[Bruno Postle]

On Mon, 27 Dec 2021, 00:33 Jon Schewe, wrote:

On Mon, 2021-12-27 at 00:20 +0000, Bruno Postle wrote:

For your document assembly project, you will need to use all of these, but not all at once - this can confuse the optimiser. I suggest starting with translation, then adding position, then view and finally add barrel

That helps, let me restate to make sure I understand.

Position refers to how the camera is rotated relative to the paper. So assuming the center of the camera is always at the center of each image and the distance to the image is the same, this corrects for how the camera may have rotated around a point.

Yes

View seems like it would be also covered by the position if using the same camera for all images. Am I correct?

The angle of view is the width of the lens, so a telephoto lens might have an angle of view of 5°, or a wide-angle lens might have an angle of view of 70°.

Translation is how the center of the camera has changed relative to the center of the image. Am I correct that x and y are left/right and up/down and z is the distance the camera is from the object?

Barrel fixes straight lines being curved.

Yes and yes.

I did find that telling Hugin to use separate lenses for each of the 2 images helps quite a bit. 

I stumbled upon this tutorial that suggested using 2 lenses http://hugin.sourceforge.net/tutorials/scans/en.shtml

This is a similar case, but you have handheld photos taken with a camera (generally called a 'mosaic'), so you have to optimise rotation as well as translation.

Note also that you are assembling your images into a plane, so you need to set the output projection to rectilinear, not equirectangular.

-- 

Bruno

[Jon Schewe]

When I specify recilinear as the output projection I get a warning from Hugin "With a wide field of view, panoramas with rectilinear projection get very stretched towards the edges. For a very wide panorama, try equirectangular projection instead. You could also try Panini projection.".

Am I correct this warning doesn't apply because what I'm creating is technically a "mosaic" instead of a "panorama"?

As far as applying translations and images ending up on top of each other. I've gotten my project into a state where Hugin believes that all images are on top of each other at the same location. To fix this I'm trying to optimize just 3 of the images by specifying "only use control points between activated images" and only have 3 images shown. Each of the images has plenty of control points linking them and all of the control points look good. However I get one image at the pole of the sphere and the other two in the center (where they belong). See the attached screenshot from the layout window. 

With a small experiment I managed to get into this state by telling Hugin to optimize X, Y, Z only for the images. It ran the optimize and told me that the average distance between all control points was zero. At this point the project appears to be in an unusable state.

[johnfi...@gmail.com]

I'm trying to learn a bit more myself, as well as hopefully help.

One thing that likely will help explain what is happening:  In expert interface, in the photos tab, in the radio buttons on the right, select "positions".  Some of the data displayed there should help explain what is going wrong.  You can also double click any row and edit the values.

If I understand correctly, yaw, pitch and roll are in degrees.  They should all be near zero, but degrees are a small unit, so values like 1 to 5 may be considered near zero.

X and Y should hold the major values BUT I don't yet understand what units they are in:  In the test I just ran, they must be quite big units because a value of 0.1 is big.

[johnfi...@gmail.com]

" you will need to use all of these, but not all at once - this can confuse the optimiser. "

I want to understand that detail.  Photos tab: Optimize Geometric: the calculate button:

Does it start from zero when you click it or does it start from wherever any previous optimize finished?  Your statement, that I want to understand, implies that previous values of its outputs influence it.

In other kinds of software, a typical optimizer can find a local optimum in the parameter space that might be much worse than the global optimum, so the starting point can make a big difference.  I don't know whether that is what you mean by "confuse".

I tried to find such an effect with a simple experiment and failed.  But likely because the experiment was too simple (If what you meant was a local optimum problem, not all sets of images and control points would even have any local optima).

[Bruno Postle]

On Mon, 27 Dec 2021, 12:47 Jon Schewe, wrote:

When I specify recilinear as the output projection I get a warning from Hugin "With a wide field of view, panoramas with rectilinear projection get very stretched towards the edges. For a very wide panorama, try equirectangular projection instead. You could also try Panini projection.".

Am I correct this warning doesn't apply because what I'm creating is technically a "mosaic" instead of a "panorama"?

Yes, but with a mosaic the z values of the camera/photo positions can be closer to the 'canvas' than the panorama viewpoint, in which case the panorama angle of view can be anything.

With a small experiment I managed to get into this state by telling Hugin to optimize X, Y, Z only for the images. It ran the optimize and told me that the average distance between all control points was zero. At this point the project appears to be in an unusable state.

Maybe attach a PTO project (no need for the images), it may be obvious what the problem is.

-- 

Bruno

[Bruno Postle]

On Mon, 27 Dec 2021, 13:24 johnfi...@gmail.com, <johnfi...@gmail.com> wrote:

X and Y should hold the major values BUT I don't yet understand what units they are in:  In the test I just ran, they must be quite big units because a value of 0.1 is big.

The 'camera' for the output panorama is at 0,0,0 and the canvas where all the images are projected is at a Z distance of 1. So for a mosaic, each of the photos are likely to have a Z value between 0 and 1.

-- 

Bruno

[Bruno Postle]

On Mon, 27 Dec 2021, 13:41 johnfi...@gmail.com, <johnfi...@gmail.com> wrote:

" you will need to use all of these, but not all at once - this can confuse the optimiser. "

I want to understand that detail.  Photos tab: Optimize Geometric: the calculate button:

Does it start from zero when you click it or does it start from wherever any previous optimize finished?  Your statement, that I want to understand, implies that previous values of its outputs influence it.

It starts at the previous values, so if you are stuck in a local minima you may have to reset all the values and start from the beginning.

In other kinds of software, a typical optimizer can find a local optimum in the parameter space that might be much worse than the global optimum, so the starting point can make a big difference.  I don't know whether that is what you mean by "confuse".

Yes, the simplest way to get stuck in a local minima is by having angle of view for all photos at 0 (this is so easy that Hugin has various built-in workarounds to avoid this).

There other ways to get stuck, particularly barrel distortion can be so extreme that only resetting it all to 0 will get you out.

-- 

Bruno

[Jon Schewe]

Attached.

[Donald Johnston]

Bruno, when hugin loads a number of photos does it base its initial Z value for the output camera on the photo marked as the anchor?

And then optimize other Z values to that?

Don J

[johnfi...@gmail.com]

On Monday, December 27, 2021 at 9:56:13 AM UTC-5 bruno...@gmail.com wrote:

 all the images are projected is at a Z distance of 1.

 

I'm taking that as the definition of the units X, Y and Z are all in.  I want to use some math to verify that I understand what that means.

I suddenly realize I don't know whether we normally talk about "angle of view" horizontally or diagonally.  I'm more comfortable with horizontal.

If I'm doing my trig correctly, the width of the field of view matches its distance when the angle of view is 53.13 degrees.  If that was the total angle of view of the resulting mosaic, then the X value of each photo would range from -0.5 though +0.5 based on the fraction of full mosiac width that each component photo is off center.

For a narrower angle of view, those X numbers would be smaller (as in the test I mentioned in which 0.1 was a "large" value for X).

The range -0.5 to 0.5 would be shifted if the anchor image were off center, and could also be increased or decreased if the yaw were nonzero.

For a rough understanding of the scale of X, Y have I got that right?

[johnfi...@gmail.com]

The images are merged together in a stack.  That is almost certainly wrong.  I don't know why that happened nor how to undo it.

I don't know how to learn more that the above from a .pto file without the images (I'm not at all the expert that Bruno apparently is).

[Bruno Postle]

On Mon, 27 Dec 2021, 15:37 Donald Johnston, wrote:

Bruno, when hugin loads a number of photos does it base its initial Z value for the output camera on the photo marked as the anchor?

And then optimize other Z values to that?

The xyz values for the viewpoint of the output panorama are always 0,0,0. When you create a new project, all the photos are initially assigned 0,0,0 as well, since the assumption is that you are not doing any translation/mosaic trickery.

-- 

Bruno

[dgjohnston]

Bruno … thanks for your quick responses on this forum.  It is very much appreciated.

1. Am I correct in saying that when hugin optimizes for translation that the canvas always stays at 0,0,1 and then the x,y,z values basically move the camera position of each photo so that the control points line up as best as possible?

2. When hugin optimizes for translation is there one photo that stays at Z=0?

Don J.

-- 

Bruno

--
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 hugin-ptx+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/CAJV99Zj8KUb8ezKExwEOa4DNGH1vhnyEFP_ssFoYzyCzSZ4ukg%40mail.gmail.com.

[johnfi...@gmail.com]

I was curious enough (after not seeing a reply to your attached .pto file from Bruno, to look up something I'd seen before but forgotten.

In the documentation of "i" lines in the .pto file it says:

# Parameters in different images can be linked using '='

# followed by the image number starting with 0.

# Example 'v=0' sets horizontal field of view as in

# image number 0. This feature works for the variables

# v, a, b, c, (r, p, y with caution) d, e, g, and t

In your .pto file, each image other than the anchor has a line like:

i w4608 h3456 f0 v=0 Ra=0 Rb=0 Rc=0 Rd=0 Re=0 Eev3.85299770079307 Er1 Eb1 r=0 p=0 y=0 TrX=0 TrY=0 TrZ=0 Tpy=0 Tpp=0 j0 a=0 b=0 c=0 d=0 e=0 g=0 t=0 Va=0 Vb=0 Vc=0 Vd=0 Vx=0 Vy=0  Vm5 n"IMG_20210728_114219.jpg"

All those = in that line force every parameter to match the parameters of the anchor image, so optimize can't optimize anything.

Inside Hugin, I don't know how to undo all that.  In a text editor, it is trivial to undo (global replace of =0 with 0 in the section holding all the i lines.  I don't know if the result of that is correct enough to get you back on track.  But I'll attach it in case it helps.

On Monday, December 27, 2021 at 10:22:19 AM UTC-5 Jon Schewe wrote:

[Bruno Postle]

On Mon, 27 Dec 2021, 15:43 johnfi...@gmail.com, wrote:

On Monday, December 27, 2021 at 9:56:13 AM UTC-5 bruno...@gmail.com wrote:

 all the images are projected is at a Z distance of 1.

 

I'm taking that as the definition of the units X, Y and Z are all in.  I want to use some math to verify that I understand what that means.

I suddenly realize I don't know whether we normally talk about "angle of view" horizontally or diagonally.  I'm more comfortable with horizontal.

panotools/Hugin uses the horizontal angle of view in degrees. There is a quirk which is that the lens parameters are mapped to the narrowest dimension of the image which is not the width for landscape images.

If I'm doing my trig correctly, the width of the field of view matches its distance when the angle of view is 53.13 degrees.  If that was the total angle of view of the resulting mosaic, then the X value of each photo would range from -0.5 though +0.5 based on the fraction of full mosiac width that each component photo is off center.

For a narrower angle of view, those X numbers would be smaller (as in the test I mentioned in which 0.1 was a "large" value for X).

The range -0.5 to 0.5 would be shifted if the anchor image were off center, and could also be increased or decreased if the yaw were nonzero.

For a rough understanding of the scale of X, Y have I got that right?

Yes I think so

-- 

Bruno

[Bruno Postle]

On Mon, 27 Dec 2021, 18:38 dgjohnston, wrote:

Bruno … thanks for your quick responses on this forum.  It is very much appreciated.

1. Am I correct in saying that when hugin optimizes for translation that the canvas always stays at 0,0,1 and then the x,y,z values basically move the camera position of each photo so that the control points line up as best as possible?

Yes

2. When hugin optimizes for translation is there one photo that stays at Z=0?

Usually yes, the anchor photo will stay at 0,0,0, but you can put it wherever you like, and dragging the set around the preview in 'mosaic' mode will change the xy values

-- 

Bruno

[Jon Schewe]

Thank you. I tried loading it and then doing an optimization and just get "Field of View must be positive". The FOV has positive values in it, so I'm not sure what it's upset about.

--
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 hugin-ptx+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/81dd2308-3a0a-4aaf-aa82-6add529fef36n%40googlegroups.com.

[johnfi...@gmail.com]

Oops.  I should have realized that would happen (Never before tried to work with a .pto without images).

Did you add control points by hand or just let the program add them automatically?

If automatically, you have no serious value in the .pto file, so unless this is pure learning (preparation for recovery from future accidents) starting over might be easier.  But in case you do have value in the .pto file, here is the correction to that field of view problem.  I wouldn't bet that was my only error, but maybe:

[Jon Schewe]

Thank you. That loads and will optimize now. Based on the initial results I'm not so sure that Hugin will be able to get itself out of this state. I have a lot of manual control points that I'd rather not recreate, but may need to. 

Lesson learned, save the project with a new name after all changes.

[johnfi...@gmail.com]

I hope you paid attention to the various advice Bruno gave you during this thread.

One part of that, likely important, that I knew nothing about before this thread, but now think I understand (and hope you do to):

You should use the custom parameters selection together with the optimize tab in Hugin to optimize the major parameters of your project before the various other parameters.  In an ordinary panorama, yaw (and in some cases pitch) are the major parameters.  But the way you took the original photos makes those very minor parameters.  Translation X and Y (and probably Z) are your major parameters.  So you want to optimize those first, probably save the .pto file after optimizing those, then optimize including other parameters: yay, pitch, roll and maybe view and maybe barrel and maybe some of the others.

[johnfi...@gmail.com]

I forgot to mention:  In the optimizer tab, you can right click at the top of any parameter column to select or deselect the whole column.  That will save you a lot of clicks when working with a large number of images.

[Bruno Postle]

On Mon, 27 Dec 2021 at 15:22, Jon Schewe <jpsc...@mtu.net> wrote:

With a small experiment I managed to get into this state by telling Hugin to optimize X, Y, Z only for the images. It ran the optimize and told me that the average distance between all control points was zero. At this point the project appears to be in an unusable state.

Maybe attach a PTO project (no need for the images), it may be obvious what the problem is.

Attached.

I needed to change the output projection from cylindrical to rectilinear, the panorama angle of view to 120 degrees, and the canvas size to a more reasonable 10000 pixels. The angle of view of 69 degrees for the input photos seemed credible.

As already noted, for some reason all the photos were assigned to the same stack, so I gave them all a separate stack in the photos tab (I've never seen this problem in a project before).

I deleted all the horizontal and vertical control points, these shouldn't be necessary for a mosaic unless there are a lack of other features to use for alignment. You may want to reintroduce a handful, just to straighten things up a bit.

I set optimise -> custom parameters in the photos tab, and then in the optimiser tab optimised just X and Y (except the first anchor image) to get an initial layout, then I added in the Z parameter for all images (except the anchor image) and optimised again. At this point I had a maximum error of about 200 pixels which shows that this initial layout is more or less ok.

Then I added in yaw, pitch and roll for all images (I didn't optimise roll for the anchor, otherwise the whole panorama might spin without a horizontal or vertical control point). This got the maximum error down to 120 pixels, so better but not great.

Then I optimised the angle of view of your lens, which reduced from 69 degrees to 20 degrees - this is a big difference, if Hugin detected 69 degrees in the first place then this would be a bug.

I deleted some obviously bad control points: when a pair of images has a good spread of control points, but one of them has a much higher error distance, this is a sign that this point needs deleting.

So after all this, the average error is 10 pixels and the maximum error is 45, this may be the best you can get with this panorama.

Attached, resulting PTO project.

--

Bruno

--

Bruno

[johnfi...@gmail.com]

Wow.

How do you work with a .pto file without images?  Create dummy images with all the correct names?  Or something simpler?

[Luís Henrique Camargo Quiroz]

   Hi John,

   Bruno uses ptodummy to create images for the pto file. It is just one of the very useful tools from Panotools-Script: https://metacpan.org/dist/Panotools-Script

   I will just intall those tools in a new system now ;)

   regards,

   Luís Henrique

  

--

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 hugin-ptx+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/265b7090-9719-4225-bc00-c9cb8d1c850bn%40googlegroups.com.

--

--
Luis Henrique Camargo Quiroz
http://luishcq.br.tripod.com - http://www.christusrex.org/www2/cantgreg
http://panoramaslh.net/

[johnfi...@gmail.com]

Those tools look like they would be great to have.

So I went down the rabbit hole of try to install that, then try to install the thing its install script needs, then try to install the thing needed by the thing needed, then fail.

Open source on Windows is often a nightmare.

[Jon Schewe]

On Mon, 2021-12-27 at 22:56 +0000, Bruno Postle wrote:

On Mon, 27 Dec 2021 at 15:22, Jon Schewe <jpsc...@mtu.net> wrote:

With a small experiment I managed to get into this state by telling Hugin to optimize X, Y, Z only for the images. It ran the optimize and told me that the average distance between all control points was zero. At this point the project appears to be in an unusable state.

Maybe attach a PTO project (no need for the images), it may be obvious what the problem is.

Attached.

I needed to change the output projection from cylindrical to rectilinear, the panorama angle of view to 120 degrees, and the canvas size to a more reasonable 10000 pixels. The angle of view of 69 degrees for the input photos seemed credible.

As already noted, for some reason all the photos were assigned to the same stack, so I gave them all a separate stack in the photos tab (I've never seen this problem in a project before).

This seems to happen when I reset the positions and then try and optimize positions. I have been telling Hugin to optimize X, Y, and Z.

I deleted all the horizontal and vertical control points, these shouldn't be necessary for a mosaic unless there are a lack of other features to use for alignment. You may want to reintroduce a handful, just to straighten things up a bit.

I set optimise -> custom parameters in the photos tab, and then in the optimiser tab optimised just X and Y (except the first anchor image) to get an initial layout, then I added in the Z parameter for all images (except the anchor image) and optimised again. At this point I had a maximum error of about 200 pixels which shows that this initial layout is more or less ok.

Then I added in yaw, pitch and roll for all images (I didn't optimise roll for the anchor, otherwise the whole panorama might spin without a horizontal or vertical control point). This got the maximum error down to 120 pixels, so better but not great.

Then I optimised the angle of view of your lens, which reduced from 69 degrees to 20 degrees - this is a big difference, if Hugin detected 69 degrees in the first place then this would be a bug.

I never manually set the angle of view, so Hugin detected it this way. 

I deleted some obviously bad control points: when a pair of images has a good spread of control points, but one of them has a much higher error distance, this is a sign that this point needs deleting.

That's interesting. I hadn't been looking at the distances. I had been looking at the images and trying to be very careful to put all of the control points in the right places.

So after all this, the average error is 10 pixels and the maximum error is 45, this may be the best you can get with this panorama.

Attached, resulting PTO project.

Thank you for all of that. I just rendered it and it looks beautiful.