hugin-devs team mailing list archive

[ner0 <1307023@xxxxxxxxxxxxxxxxxx>]

Fair enough, I misunderstood the OP's problem and took it as the same
issue.

Nevertheless, I was curious about the limitation that I tried stitching
something bigger, even though I don't plan on actually stitching such
big images in the near future. The test I did succeeded but I'm not sure
if the shortcuts taken during this test might have had anything to do
with a perceived success.

Since I didn't have big enough images I created six identical
32000x32000 JPG images with Photoshop, completely white; I'm not sure if
this might have influenced the success of the stitching process. Because
they are plain white JPGs they are only 10.7MB each. Not sure if this
counts for testing purposes, also worth mentioning that the output TIFF
was only 20MB.

This is my system:
- OS: Windows 10 x64
- CPU: Intel Core i7-4770K @ 3.5GHz
- RAM: 16GB DDR3

Software and resources used:
- Photoshop CC
- Six identical white 32000x32000 JPGs
- cubic2erect bundled with Panotools-Script-0.22-win32
- nona and dependencies bundled with Hugin 2016.2 RC2 64bit

In my system, the whole process took around ~25min.
I ended up with an equirectangular TIFF with a size of 100530x50265 = 5.053.140.450 pixels (more than double the mentioned limit of 2^31).

-- 
You received this bug notification because you are a member of Hugin
Developers, which is subscribed to Hugin.
https://bugs.launchpad.net/bugs/1307023

Title:
  nona crashes with std::bad_alloc when input has more than 2^31 pixels

Status in Hugin:
  Won't Fix

Bug description:
  I would like to create cube faces for a 360° Panorama that is currently in equirectlinear projection with a size of 155.110 x 51.338 pixels (not full 180° height, top and bottom are cut away) - so a total pixel count of 7.963.037.180
  It's currently in png format, since most programs don't seem to know that with bigtif a tif can be bigger than 4gb.

  I like to use erect2cubic from the Panotools::Script cpan package. This creates a pto file which then needs to be called with nona:
  erect2cubic --erect=equirectlinear.tif --ptofile=cube.pto; nona -o prefix cube.pto

  This works perfectly when the total pixel count is smaller than 2^31.
  I am searching for a solution for bigger panoramas.

  enblend suffers from the same limitation, theres an quite old bug report in the enblend launchpad tracker
  https://bugs.launchpad.net/enblend/+bug/685105
  that sort of ended with the statement that panoramas with more than 2^31 are out of the scope of what enblend want's to achieve.
  Does this apply to nona too?

  Is there some hint any of the devs can give me how to work around this problem?
  In two of my previous panoramas I've stiched the 4 relevant faces seperatly directly with a linear projection, though I dislike this aproach because it's nearly impossible to make the 4 seams manually match. See:
  https://kaefert.is-a-geek.org/SaladoPlayer-1.3.5/?pano=blindengasse55_2014-01-10&view=43,0,12
  https://kaefert.is-a-geek.org/SaladoPlayer-1.3.5/?pano=koega_2013-11-27&view=44,-1,10

To manage notifications about this bug go to:
https://bugs.launchpad.net/hugin/+bug/1307023/+subscriptions