Hugin (et al.) vertically squeezes my long panorama

Bug #1815854 reported by Scott Cowles Jacobs on 2019-02-14
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
hugin (Ubuntu)
Undecided
Unassigned

Bug Description

I have a long horizontal panorama (16 photos), that I took with a tripod.

I opened the images, and told Hugin to align them

I used the Move/Drag tab to slightly rotate the image to be more horizontal.

I used the Crop tab to approximately match the top/bottom/right/left edges (the pictures being so little, it is almost impossible to see whether I am enclosing any areas outside the image - but I can fix that in GIMP with cropping or Heal Selection later).

I tell Hugin to Create Panorama.

As it is printing its output to the progress window, I suddenly notice that the bounding box of the crop is extending at least 100% below the line where I had set it.

When I looked at the image, there was a large area of black below the image,

My images are 4000 wide by 3000 tall. Taken on a tripod, I would expect the height of the resultant panorama to be somewhere around 3000.
Indeed, in GIMP, the total height of the image is 3013 (even closer to 3000 than I expected). However, that includes the area of black at the bottom. The actual height of the image is somewhere in the neighborhood of 1700. Thus Hugin has reduced the height of my image to about half.
The image itself does not appear to be flattened, and it appears to be complete, so I suppose that it also has been reduced the same amount horizontally. 16 images times 4000 pixels means that the upper bounds for the width would be 64000 pixels, and the actual width is 30000.
If we assume that I overlapped by an average of 25%, I would expect it to be about 48000.
I am sure I did not overlap by over 50% (30000/64000 = ~.47).
"Downscale final pano" 100 "percent of max. width"

I have tried to find out where the log files for the stitching are, but have been unable to do so so far. The clipboard only shows the alignment log.
Perhaps there are command-line options to enblend/enfuse that will let me direct the log output to a file of my choosing, but a quick check of the docs (too quick, likely...) does not appear to show options for that. I don't know if one can use re-direct (">") output on the "executable" or "default arguments" lines in the preferences, but I can try that...
I could also perhaps start Hugin from the terminal, and capture output that way...

If anyone has suggestions, either how to stop Hugin from shrinking my panorama, or how to see the output to better debug the problem, please let me know.

---------------------------------------------------
scott@scott-Asus-M2N68-AM-PLUS:~$ uname -a
Linux scott-Asus-M2N68-AM-PLUS 4.13.0-46-generic #51-Ubuntu SMP Tue Jun 12 12:36:29 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
scott@scott-Asus-M2N68-AM-PLUS:~$ lsb_release -dsc
Ubuntu 17.10
artful
scott@scott-Asus-M2N68-AM-PLUS:~$ echo $DESKTOP_SESSION
QLubuntu

scott@scott-Asus-M2N68-AM-PLUS:~$ apt-cache policy hugin*
hugin:
  Installed: 2018.1.0+hg7969+dfsg-0ubuntu1~artful
  Candidate: 2018.1.0+hg7969+dfsg-0ubuntu1~artful
  Version table:
 *** 2018.1.0+hg7969+dfsg-0ubuntu1~artful 500
        500 http://ppa.launchpad.net/hugin/nightly/ubuntu artful/main amd64 Packages
        100 /var/lib/dpkg/status
     2017.0.0~rc2+dfsg-2 500
        500 http://us.archive.ubuntu.com/ubuntu artful/universe amd64 Packages

(I was using 2017.0.0~rc2+dfsg-2 (Standard for [L]ubuntu 17.10) originally, but noted that
elsewhere, a more recent version was available, and thought that perhaps the "bug" (?) had been fixed there. Alas, no...
Hugin itself prints "2018.1.0.aac6fbdf0772" for my current version, from the "Help" menu.)

scott@scott-Asus-M2N68-AM-PLUS:~$ apt-cache policy enblend
enblend:
  Installed: 4.2-2build2
  Candidate: 4.2-2build2
  Version table:
 *** 4.2-2build2 500
        500 http://us.archive.ubuntu.com/ubuntu artful/universe amd64 Packages
        100 /var/lib/dpkg/status
scott@scott-Asus-M2N68-AM-PLUS:~$ apt-cache policy enfuse
enfuse:
  Installed: 4.2-2build2
  Candidate: 4.2-2build2
  Version table:
 *** 4.2-2build2 500
        500 http://us.archive.ubuntu.com/ubuntu artful/universe amd64 Packages
        100 /var/lib/dpkg/status

I note that this PPA has a more recent enblend and enfuse, but that it is apparently now one package, and apparently also is not available for "artful"...

---------------------------------------------------

I don't know yet, if enblend/enfuse are messing with the image dimensions, or they are working correctly with incorrect information sent from Hugin...

Any ideas?

tmodes (tmodes) wrote :

Can you provide the pto file which shows the described behaviour?

Changed in hugin (Ubuntu):
status: New → Incomplete

Here is the .pto file requested.

tmodes (tmodes) wrote :

I can't reproduce the issue. I loaded your project and pressed calculate optimal size. The results was 53352x6474 (with the black border).
Then it tried "Fit" + "Calculate size"+"auto crop" to get rid of the black border. The results was "53199x2785". This is in the range, you expected, isn't it.
The change of the crop during stitching I can't reproduce. I set the crop and this one was used during stitching. Maybe there was an unintentional mouse click?

No. I was able to reproduce it several times.

When I get a minute, I will Simple Screen Recorder a video showing the process.

OK. I have done the SSR recording of the process, and will attach it, and the .log file (to which I added the terminal output), and the stitching log and the .pto file.

The logs are from a run later than the one in the video, but it looked and achieved exactly the same thing (I had somehow messed up the log).

tmodes (tmodes) wrote :

Fixed in repository.

Changed in hugin (Ubuntu):
status: Incomplete → Fix Committed

I take it that you found the problem?
Boy - that was fast!

I am curious what it was...

Also,

If it has been fixed, please let me know where and when I can access the fixed version for "artful", so I can help verify that it now works.

tmodes (tmodes) wrote :

The input field had a maximum value of 30000 pixels set. So when trying to set the correct value of 50000x3000 or so about the width was truncated to 30000, but the height remained unchanged. This resulted in the changed cropped.

We are currently in the release cycle for 2019.0. The fix will be in rc1. But I don't know when the packages for Ubuntu are updated.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers