Hello. Sorry to come into this old discussion. I see that the status of this bug report is "Won't Fix" but the last user before me mentioned that it might be possible to build the VIGRA library using a 64bit compiler and overcome the limitation. I'd like to help out but don't know where to start. I'm not a coder but I'm facing the exact same problem where cubic2erect will fail when using nona with the error "std::bad_alloc".
I tried getting the 64bit compiled version of vigraimpex and using that instead of libvigraimpex but needless to say that I don't know what I am doing. I almost had success using Hugin's 2015 64bit version but that gave me another different error: ERROR: (c:\users\harryvanderwolf\downloads\hugin-sdk\sdk\hugin-2015.0.0\src\hugin_base\nona\Stitcher.h:547) HuginBase::Nona::WeightedStitcher<class vigra::BasicImage<class vigra::RGBValue<unsigned char,0,1,2>,class std::allocator<class vigra::RGBValue<unsigned char,0,1,2> > >,class vigra::BasicImage<unsigned char,class std::allocator<unsigned char> > >::stitch(): exception during stitching Precondition violation! separableConvolveX(): kernel longer than line (c:\users\harryvanderwolf\downloads\hugin- sdk\sdk\vigra\include\vigra\separableconvolution.hxx:1103) Nevertheless it produced the final image (527 MB - 25132x12566px) with 85% accuracy. The missing 15% are because it is literally missing a full chunk (always the right side of the cubic panorama). EDIT: Well, I was about to finish this off when I browsed through the sourceforge folders and saw the 2016.2 RC2 64bit version. And what do you know, it solves the issue completely! No more errors or missing chunks, it just works! Thanks to the community and mainly the developers for all their hard work. Cheers! -- 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 _______________________________________________ Mailing list: https://launchpad.net/~hugin-devs Post to : [email protected] Unsubscribe : https://launchpad.net/~hugin-devs More help : https://help.launchpad.net/ListHelp
