stitching cylindrical pano from rectilinear images results in vertical mismatch at ends

[James Proctor]

Greetings -- I'm using Hugin to stitch together some old digital images taken from a Nikon Coolpix atop a tripod/pano mount (14 total per pano). There was plenty of overlap btw all images, including the first and last image. The stitching process seems to work great, but when I export and view the pano the vertical position of elements at the left and right ends is off, resulting in a jagged transition...see e.g. attached. 

The settings I used are as follows:

1. Load Images: Lens type rectilinear, 3.8mm/13.7 multiplier (automatically detected?)
2. Projection switched from default Rectilinear to Cylindrical
3. I've played a bit with Center/Fit/Straighten buttons, but they don't seem to do the trick

There must be an easy explanation as to why the stitching process doesn't align the two ends of the pano, given the original images overlap substantially. It just doesn't seem to recognize that these 14 images are from a quasi-cylindrical (vs. e.g. planar) source.

If you could please point me to a ready solution I'd sure appreciate! The app is proving useful for me to re-stitch circa 2000 digital panos previously saved in now-extinct QTVR format.

Regards,

Jim Proctor

[Erik Keever]

Hi Jim,

Offhand possibility...

The 1st and last images overlap but do they have control points between them? I don't believe the bulk detectors do this by default. If they lack CP, small alignment errors from N to N+1 will accumulate & make the ends mismatch.

-- Erik

--
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/8afa78b6-241e-4e65-ae93-a8aa6e8ea319%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Greg 'groggy' Lehey]

On Sunday, 28 April 2019 at 16:34:44 -0700, James Proctor wrote:
> Greetings -- I'm using Hugin to stitch together some old digital images
> taken from a Nikon Coolpix atop a tripod/pano mount (14 total per pano).
> There was plenty of overlap btw all images, including the first and last
> image. The stitching process seems to work great, but when I export and
> view the pano the vertical position of elements at the left and right ends
> is off, resulting in a jagged transition...see e.g. attached.

My first thought looking at that pano is that the horizon looks as if
it has been bent. Is the ground really like that? In particular, the
trees at the left are leaning to the left, but they're coming out of
the ground at 90°.

Do you have vertical control points? I've found them to be more of a
problem in this kind of pano. Check in the Assistant tab: uncheck
"Detect vertical lines".

Otherwise if you can put the source images somewhere, we can take a
look at them.

Greg
--
Sent from my desktop computer.
Finger groo...@gmail.com for PGP public key.
See complete headers for address and phone numbers.
This message is digitally signed. If your Microsoft mail program
reports problems, please read http://lemis.com/broken-MUA

[Bruno Postle]

A couple of things:

If these input images are cylindrical, Hugin won't detect this automatically, you need to set the input projection to cylindrical (in addition to the output projection).

Cylindrical images are often cropped, meaning that the horizon doesn't run through the middle of the image, in this case you need to optimise the 'e' parameter in addition to 'v, r, p & y'. This itself would explain the dislocation you are seeing.

How are you extracting the images from the MOV files? Somewhere we have a Hugin tool for parsing QTVR data and reassembling a panorama automatically - would this be useful?

--
Bruno

On 29 April 2019 00:34:44 BST, James Proctor wrote:
>Greetings -- I'm using Hugin to stitch together some old digital images
>
>taken from a Nikon Coolpix atop a tripod/pano mount (14 total per pano).
>There was plenty of overlap btw all images, including the first and last
>image. The stitching process seems to work great, but when I export and
>
>view the pano the vertical position of elements at the left and right ends
>is off, resulting in a jagged transition...see e.g. attached.
>
>The settings I used are as follows:
>

> 1. Load Images: Lens type rectilinear, 3.8mm/13.7 multiplier
> (automatically detected?)
> 2. Projection switched from default Rectilinear to Cylindrical
>3. I've played a bit with Center/Fit/Straighten buttons, but they don't

[James Proctor]

Thank you, all, for your replies so far!...very helpful. Quick responses:

• I haven't been using control points, and assumed the overlap btw first/last image would render stitching possible. By establishing control points btw first/last image, would this in effect tell Hugin that I have a 360° set of images? My intuition suggests there would be a simpler way to do this.
• The tripod head was set to level when I shot all these images, which are on considerable terrain, hence they may appear to be off vertically but they're not. (And here too, I did not manually input control points given the pano head I used to establish careful overlap btw images.) I attach a zipped version of input files to this reply.
• Each input image is flat/rectilinear. Collectively, the fourteen images describe a 360° view. I tried (once, maybe incorrectly?) to set the Lens Type from Normal (rectilinear) to Panoramic (cylindrical), but the result was goofy. I have been setting Projection (all this via Simple interface) to Cylindrical prior to stitching; where would the input projection be set, if I understand your recommendation correctly? (Btw, my QTVRs are at less resolution than the originals, so I'd prefer to start with the originals at this point.)

I hope the above is helpful. My gut tells me that there is some setting I'm missing that tells Hugin my images comprise a 360° view, thus it would stitch the first and last together as two adjacent images, same as the rest.

Sure appreciate any continued ideas,

Jim P.

[Abrimaal]

The horizon looks very good, the trees are straight and the hills naturally curved.
I see that the sky colors don't look natural.
This has been caused by the automatic exposure and white balance correction.
When you use "Align" button, the exposures and WB are adjusted, but they rather adjust the dark tones - this is why the ground looks very good.
Try to reset the photometric parameters in the Panorama editor and save a new panorama.
The new panorama may have differences in the exposures of the ground, but the sky will look good.

Then load both panoramas into Hugin, set rectilinear projection,
Edit image variables: set yaw, pitch, roll to 0 (this will overlay both panoramas)
Now use masks - include mask for this part of image where the ground looks good, and other include mask where the sky looks good... and save a new panorama from stacks using the Stitcher.

[James Proctor]

Thanks for these suggestions; I think I now get how to optimize exposure by overlaying two panos set for different exposures.

If you have ideas re. my bigger problem of creating a true 360° pano from the original fourteen images, I'd appreciate! See earlier posts in thread for clarification.

Jim P.

On Sunday, April 28, 2019 at 10:40:58 PM UTC-7, James Proctor wrote:

[Greg 'groggy' Lehey]

On Monday, 29 April 2019 at 18:19:23 -0700, James Proctor wrote:
> If you have ideas re. my bigger problem of creating a true 360° pano
> from the original fourteen images, I'd appreciate! See earlier posts
> in thread for clarification.

As I suggested, put the images somewhere where somebody can take a

[James Proctor]

Um, I did!...see my reply from earlier today (PanoImages.zip).

Sure appreciate,

Jim P.

[Greg 'groggy' Lehey]

On Monday, 29 April 2019 at 19:04:23 -0700, James Proctor wrote:
> On Monday, April 29, 2019 at 6:26:49 PM UTC-7, Groogle wrote:
>>
>> On Monday, 29 April 2019 at 18:19:23 -0700, James Proctor wrote:
>>> If you have ideas re. my bigger problem of creating a true 360° pano
>>> from the original fourteen images, I'd appreciate! See earlier posts
>>> in thread for clarification.
>>
>> As I suggested, put the images somewhere where somebody can take a
>> look at them.
>

> Um, I did!...see my reply from earlier today (PanoImages.zip).

Oh. I wasn't expecting them as an attachment. That's generally
frowned upon because of the size, though in this case it's not too
bad.

These images stitch out of the box for me. Take a look at
https://lemis.nyc3.digitaloceanspaces.com/grog/Photos/20001224/small/Pano-orig.jpeg
and
https://lemis.nyc3.digitaloceanspaces.com/grog/Photos/20001224/small/Pano.jpeg.
The former is literally without any tweaks, the latter has been
automatically optimized for colour. The project file is at
http://www.lemis.com/grog/Photos/20001224/DSC00001-DSC00014.pto

So what went wrong with your stitching? I really don't know. I
checked my suspicion that it might be the vertical control points, but
even with them it worked perfectly. I did this a couple of times,
once with a focal length multiplier of 8, the other with 10, and they
both worked fine. The best you could do would be to compare the
project file with the one I refer to above.

[Erik Keever]

Hi Jim,

What do you mean not using control points? The usual process is

(1) Load pictures

(2) Detect control points

(2b) Prune bad control points

(3) Have Hugin align images

(4) Stitch

The stitching process is "just" a bunch of computational geometry that projects input images onto the 4π steradians of a sphere using one set of transforms & then projects part/all of that sphere back onto an image using another.

Which is a long way to say that it doesn't matter at all if your pictures are the least bit aligned, stitching will "work."

You don't have an unreasonable (meaning about 75 or more) number of images so you should be able to simply select them all and detect CP using cpfind, then click 'optimize geometry' and Hugin will be able to line everything up with subpixel accuracy.

The key to making a 360* panorama work is to connect the "left" and "right" edges with control points and then have Hugin optimize your lens field of view. While we say e.g. that my normal lens has a focal length of 50mm, in reality it's 50.xxxxxxxx mm, and the exact number is derived by Hugin when we require that a string of images spanning 360* does in fact span exactly 360*. 

Your 'lens type' means the projection used by the lens taking the image, which is almost 100% for sure rectilinear. The thing called 'projection type'  is the projection used by the lens of the imaginary camera at the center of that sphere I mentioned that determines what gets projected onto the output image (You may notice that many of the output projections, like equirectangular or cylindrical, do mappings that are nigh impossible for any physical lens).

-- Erik

--

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/de5b921b-50e3-4865-8671-043cd8a5181d%40googlegroups.com.

[Gunter Königsmann]

With cell phone optics sometimes the upper left corner has a slightly different zoom factor than the lower right. Might it be something like this?

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

[James Proctor]

Thanks again for your help, Groogle & Erik. I'm now learning a few things that may differentiate my outcome from yours, and that may've resulted in some confusion:

• I'm running the Simple interface. (I've played with the Advanced interface, but issues with PTBatcherGUI took me back to Simple...possibly due to version noted below?).
• I'm running the Mac OS version of Hugin (2019.0.0 on OS X latest).
• I'm running cpFind as the default control point detector as set in Prefs.

With Simple interface the three-step process seemed buggy when testing this AM, but now works:

1. I Load Images (easy), then set Projection to Cylindrical.
2. I run Align; this now works in establishing control points btw my first and last image. I typically end up with ~550 automatic control points.
3. I then run Create Panorama. This barfed earlier today for some reason in the batch processor, but now seems to work fine. 

I realize I'm doing the very simple/uncorrected approach here, but it now seems to work fine. I have on order a half dozen other historical (2000-01) panos to stitch similarly, which I'll do, and report issues to this thread as relevant.

I want to thank you all for your great help. If questions re. above, feel free to ask.

Regards,

Jim P. 

On Sunday, April 28, 2019 at 10:40:58 PM UTC-7, James Proctor wrote:

[Abrimaal]

> 1. I Load Images (easy), then set Projection to Cylindrical.

> 2. I run Align;
Hugin will not remember the selected projection when you click [ Align ], because the simple Align automatically selects projection, based on the field of view.
You might not notice this, because cylindrical is the default projection for long panoramas.
But if you select Panini, Mercator or a different projection, and click Align, it will be automatically changed to cylindrical. You may always change the projection after alignment...
or use Panorama editor (find control points, vertical lines if you need, optimize positions, optionally adjust the exposures/white balance) and return to the simple preview. This sequence works the same as [ Align ] button without changing the pre-selected projection.

> This barfed earlier today for some reason in the batch processor, but now seems to work fine.

I don't know how the batch processor behaves under OS X, but under Windows it is very annoying, especially when you have sooo many panoramas to make.
With every added task, the icon of the batch processor is popping up the taskbar blocking the bottom of the screen. Until you click on the icon. I reported this bug many times, because it slows down the work, especially when there are many panoramas to stitch.