strange issues with 360 pano?

[clepsydrae]

Howdy -- I'm attempting a pano made of 14 images (~10mm on a 1.62x APS-C). CPFind doesn't find CPs well unless I drag the images to a rough correct overlap, so I do that first.

Then CPFind finds the CPs, I remove some CPs from the clouds, and optimization (Pos/Trans/View/Barrel) does a good job. (~average error of 10 pixels.)

Now the panosphere looks perfect, but the preview pane exhibits some kind of odd clipping. In this demo image you can see that the panosphere wraps around perfectly with properly aligned images, but the preview window is cut off (approx 180 degree HFOV). This is also how the image exports when stitched.

If I try to drag individual images around the panosphere, "strange" things happen. Sometimes the images become gradually clipped as they move in the panosphere, but appear normal in the preview pane. Sometimes the opposite happens: images look fine in the panosphere, but clip in the preview pane.

What am I missing?

Here are the optimized parameters.

...doesn't look too crazy, right?

Thanks for any ideas!

---------

Operating System: Linux 4.13.0-46-generic x86_64
Architecture: 64 bit
Free memory: 4812004 kiB

Hugin
Version: 2018.1.0.aac6fbdf0772
Path to resources: /usr/share/hugin/xrc/
Path to data: /usr/share/hugin/data/
Hugins camera and lens database: /home/casey/.hugindata/camlens.db
Multi-threading using C++11 std::thread and OpenMP

Libraries
wxWidgets: wxWidgets 3.0.3
wxWidgets Library (wxGTK port)
Version 3.0.3 (Unicode: wchar_t, debug level: 1),
Runtime version of toolkit used is 2.24.
Compile-time GTK+ version is 2.24.31.

libpano13: 2.9.19
Boost: 1.62.0
Exiv2: 0.25
SQLite3: 3.19.3
Vigra: 1.11.0
LittleCMS2: 2.7

[Greg 'groggy' Lehey]

On Monday, 13 August 2018 at 15:31:59 -0700, clepsydrae wrote:
> Howdy -- I'm attempting a pano made of 14 images (~10mm on a 1.62x APS-C).
> CPFind doesn't find CPs well unless I drag the images to a rough correct
> overlap, so I do that first.
>
> Then CPFind finds the CPs, I remove some CPs from the clouds, and
> optimization (Pos/Trans/View/Barrel) does a good job. (~average error of 10
> pixels.)
>
> Now the panosphere looks perfect, but the preview pane exhibits some kind

> of odd clipping. ...

I've frequently seen that the preview shows problems that don't exist
in the final stitched image. Have you tried stitching? Unfortunately
I find the panosphere pretty useless, and the views you show are hard
to interpret.

If the image doesn't stitch well, can you put the source images and
project file somewhere where people can look at them? Smaller images
are fine as long as they show the problem.

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

[clepsydrae]

Thanks, Groogle -- when the image is stitched, it stitches the same as it does in the preview, with clipped edges, only about half the expected HFOV (although the edges aren't jagged as they appear in the preview, but straight... ? )

Perhaps this .mp4 will make things a bit more clear.

Some other oddities: I noticed that the CPs between the "invisible" image pairs don't show up in the fast preview window, even though they are in fact present. See this demo image. The CPs on the "front" side of the panosphere image plane show up fine.

I have uploaded all the test images and the demo .pto here -- but be warned that it is a 2GB file. It is uploading now and should be done at the latest in ~45 minutes (18:30 PDT/UTC-7, 01:30 UTC).

Thanks for any time anyone has for this!

-c

[clepsydrae]

On Monday, August 13, 2018 at 4:58:30 PM UTC-7, Groogle wrote:

> Smaller images are fine as long as they show the problem.

...if the 2GB file is ridiculous I can try to make a small version of the issue... let me know, thanks!

[clepsydrae]

Aha -- it seems to be related to optimization of translation... I inspected the .pto and saw some extreme-seeming values for TrX, TrY, and TrZ. I started over and did not optimize translation and the issue doesn't happen.

I chose to optimize for translation because I was on a crappy tripod without any kind of calibration for the image plane vs. the pivot point -- was that a bad idea?

Here is the .pto in case it's interesting (and if you don't want to download the 2GB zip file just to see the pto.)

[Greg 'groggy' Lehey]

On Monday, 13 August 2018 at 17:50:53 -0700, clepsydrae wrote:
> I have uploaded all the test images and the demo .pto here

> <http://caseyconnor.org/pub/image/hugin/hugintest.zip> -- but be warned

> that it is a 2GB file. It is uploading now and should be done at the latest
> in ~45 minutes (18:30 PDT/UTC-7, 01:30 UTC).

OK, in the end it was only 1 GB.

On Monday, 13 August 2018 at 17:53:17 -0700, clepsydrae wrote:
> On Monday, August 13, 2018 at 4:58:30 PM UTC-7, Groogle wrote:
>>
>>> Smaller images are fine as long as they show the problem.
>

> ...if the 2GB file is ridiculous I can try to make a small version of the
> issue... let me know, thanks!

That was the background for my suggestion. But I've looked at the
original, and I think I have answers for you.

What I see is that the problems are with the source images, not Hugin:

1. The images are underexposed by about 5 EV. The control point
detectors just can't cope.

2. The images show extreme vignetting in the corners. This may be
the background for the clipping. I processed the images with DxO
Optics Pro, bringing out results that were acceptable, if not
good. DxO knows the lens/camera combination and corrected for the
vignetting in the lens, but not completely. That suggests that
there may be something wrong with your lens (or, of course, with
DxO's correction profiles). You may find things clear up with a
marginally longer focal length setting.

3. There was dirt at the top of the images, slightly to left of
centre. It wasn't visible until the images were lightened.

Take a look at
http://www.lemis.com/grog/photos/Onephoto.php?image=/grog/Photos/20180804/cedarpano.jpeg&size=3
for the results. That image is by no means perfect, but it's exactly
what Hugin did with the standard Align function. There's a
discontinuity on the board at bottom mid-left, but that could be dealt
with with a mask.

In passing, you probably don't need that many images for a circular
panorama (not 360°; that includes a complete sphere). My program
tells me steps of 50° for this lens, sensor and orientation, so 8
images (45° steps) should do it.

[clepsydrae]

Thanks for looking at it!

1.  The images are underexposed by about 5 EV.  The control point
    detectors just can't cope.

Yeah these are actually just the dark frames of a three-exposure bracketed HDR stack. Now that I have things sorted (see above) I'll incorporate the other exposures as well.

2.  The images show extreme vignetting in the corners.

That's just due to a polarizing filter on the wide-angle lens (which is why vignetting correction didn't help). The hope was that it would disappear when pano'd, and it seems it has (thankfully).

3.  There was dirt at the top of the images, slightly to left of
    centre.  It wasn't visible until the images were lightened.

Yeah. Gonna fix it in post. :-)

In passing, you probably don't need that many images for a circular
panorama (not 360°; that includes a complete sphere).

Thanks for the tip.

Here's what I've gotten to now that I'm not optimizing translation. Very happy with the results. Just need to understand why translation optimization confused it so much... maybe the CP detection on dark images, as you suggested?

[Greg 'groggy' Lehey]

On Monday, 13 August 2018 at 21:50:18 -0700, clepsydrae wrote:
> Aha -- it seems to be related to optimization of translation... I inspected
> the .pto and saw some extreme-seeming values for TrX, TrY, and TrZ. I
> started over and did not optimize translation and the issue doesn't happen.

Possibly. I'd attend to the other issues first. I'm surprised that
the control point detectors found anything on the original images.

[Greg 'groggy' Lehey]

On Monday, 13 August 2018 at 22:04:50 -0700, clepsydrae wrote:
>
> Here's what I've gotten to

> <http://caseyconnor.org/pub/image/hugin/panotest.jpg> now that I'm not

> optimizing translation. Very happy with the results. Just need to
> understand why translation optimization confused it so much... maybe the CP
> detection on dark images, as you suggested?

Certainly doing just the dark images doesn't help. But I'm probably
out of my depth here. Maybe others can venture an opinion at to what
optimization parameters make sense.

I do my panos a bit differently:

1. Take 3 images bracketed 3 EV apart, skewed about 1.3 EV towards
overexposure (+4.3 EV, +1.3 EV, -1.7 EV). I think this would work
well for your scene as well.

2. Convert images to HDR externally to Hugin (specifically,
Photomatix on a Microsoft box). Hugin doesn't handle ghosting.

3. Run the resultant images through Hugin. Until proof of the
contrary, use the Align function of the Assistant. This is what I
did with your images.

Recently I've been playing with scripting the conversions, so in
fact what I do is:

pto_gen -o my-1 $FILES
cpfind -o my-2 my-1
celeste_standalone -i my-2 -o my-3
cpclean -o my-4 my-3
autooptimiser -a -l -s -o my-5 my-4
pano_modify -o $PTO --center --straighten --canvas=AUTO --crop=AUTO my-5

The my-? are intermediate steps in the project file so that I can
see what has changed; the documentation is minimal and out of
date.

[clepsydrae]

Certainly doing just the dark images doesn't help.  But I'm probably
out of my depth here.  Maybe others can venture an opinion at to what
optimization parameters make sense.

It seems to find CPs just fine, judging by inspection of points, and given that the optimization works great (when translation is not optimized)... I've used cpfind to find good points in images much darker than these, too, and it seemed fine? (Also, these are 16bit tiffs, so there's possibly more room at the bottom of the range to work with, even if the camera doesn't really use all those bits.)

Doing some more googling, it seems that I was unwise to use translation optimization, as it's for cases where the tripod is really moved (e.g. capturing the nadir of a spherical 360 pano or other cases where the tripod is e.g. picked up and moved). I thought it was OK for small movements as well (e.g. non-calibrated non-pano-head tripod)... must have read that wrong somewhere.

This post seems to talk about something similar, but it's from 2010 so I'm not sure I should pay much attention to it...

Thanks for the scripting/HDR tips. I haven't found an automatic HDR program that can match what one can do with manual blending (using luminosity masks), but I was planning to try letting hugin make the HDR attempt, and assuming it doesn't satisfy, was going to align/pano everything in hugin, export each HDR layer separately, and then blend in GIMP. Someday I will get around pano stuff on the command line. Now that I'm finally learning how to use hugin properly, though, I like it a lot. :-)

[clepsydrae]

Aha, sounds like that 2010 post was indeed my issue: https://wiki.panotools.org/Hugin_FAQ#Why_does_my_output_covers_only_180.C2.B0.3F

"Always read the FAQ!" :-)

Upshot, as I understand it: if optimizing for translation, the pano must be less than 180 degrees HFOV.

[David W. Jones]

On August 13, 2018 9:39:34 PM HST, Greg 'groggy' Lehey <groo...@gmail.com> wrote:
>On Monday, 13 August 2018 at 22:04:50 -0700, clepsydrae wrote:
>>
>> Here's what I've gotten to
>> <http://caseyconnor.org/pub/image/hugin/panotest.jpg> now that I'm
>not
>> optimizing translation. Very happy with the results. Just need to
>> understand why translation optimization confused it so much... maybe
>the CP
>> detection on dark images, as you suggested?
>
>Certainly doing just the dark images doesn't help. But I'm probably
>out of my depth here. Maybe others can venture an opinion at to what
>optimization parameters make sense.

I would use the exposures closest to a 'normal' exposure for finding CPs and aligning images. Just to avoid issues that might be traceable to severe over/underexposure.


David W. Jones
gnome...@gmail.com
wandering the landscape of god
http://dancingtreefrog.com

Sent from my Android device with F/LOSS K-9 Mail.