I'm affected by this bug too (at least that what it seems to me)
I'm using Ubuntu 13.04 and all packages are out of the default repositories.
I have 10GB ram and 20GB swap-space, but somehow the swap didn't get filled
more than 10% when this error happened (which seems kind of strange to me)
btw. -- is there a way to skip the nona part and directly call enblend only?
I found this name.pto.mk file and thought it might be a shellscript, but
running it like a shell script didn't work out that well.
--
You received this bug notification because you are a member of Hugin
Developers,
Okey, so I'm home again. My self-built enblend 4.1.1 failed really fast,
again with the same error:
enblend: out of memory
enblend: std::bad_alloc
But my dstat output of that time shows that the memory was nearly empty...
http://pastebin.com/raw.php?i=B9sjQaK9
So I'm gonna try the compiling
Okey, thanks, will use with me continued tests, will make it quicker,
since the nano stuff also takes around an hour every time..
So when I compile enblend (both the version 4.1.1 downloaded from sourceforge
and the version 4.0 from the ubuntu repos) with the option
--enable-image-cache=no it
I think I should be running 64bit
kaefert@ultrablech:~$ uname -a
Linux ultrablech 3.8.0-30-generic #44-Ubuntu SMP Thu Aug 22 20:52:24 UTC 2013
x86_64 x86_64 x86_64 GNU/Linux
I just found I was telling you wrong stuff, my total picture count of
this set is not 330 but 233 (so actually I was damn
well, I'm not at home, therefore got a painfully slow connection here, but you
can download the 15MB reduced files here:
http://kaefert.is-a-geek.org/misc/hugin/360degree233pics_enblend-failure/small/
The first few of the original files are in the parent directory, but the
upload from here to my
yep, correct (I used exactly your code, the only change I made was from *.jpg
to *.JPG)
I've put the project file and a few logfiles in the subdirectory stuff
I've turned on directory listing for this directory, so you can just navigate
there.
--
You received this bug notification because you
Thanks Christoph for the detailed response!
But I don't think that I've hit the MAX_INT Pixel limit with my Panoramas.
I'm trying to create 360 degree panoramas with pictures taken with my Canon
Powershot SX280HS which has a 20x zoom lense.
A panorma that covers about 90 degrees of the sky
Okey guys! First I want to thank you all for the useful information you
gave me, especially @rew for the thing with the different lenses.
And secondly If anybody is still interested in debugging the issue of this
bugentry: Today enblend failed on me again - I've been trying to create a
panorama
Okey, so I'm still not ready to let this one go ;)
I've followed this guide: http://wiki.panotools.org/Hugin_Compiling_Ubuntu
To compile and install those on my machine:
libpano13 2.9.19-789hg
enblend 4.2-7bcf8a1e6b3d
hugin 2013.0.0.6337
Now with this setup, trying to create a panorma with more
okey, so the enblending of my 240.000 x 8.292 pixel panorama succeed.
The resulting tiff file is a little under 2GB big and sadly does contain
lots of those http://kaefert.is-a-geek.org/misc/hugin
/360degree233pics_enblend-failure/artifacts-enblend-4-2/ artefacts. I
think this artefact problem I
btw., some info that might be useful for other users or maybe also for the
developers:
The sources of this panorama are 229 pictures of 3000x4000pixels.
The highest amount of memory used by enblend was 10GB RAM + 42GB Swap-space.
The enblend process took around 50 hours to finish stiching this
couldn't find a way to do that, here is the output of --version and --help
http://pastebin.com/2n4YH8F4
--
You received this bug notification because you are a member of Hugin
Developers, which is subscribed to Enblend.
https://bugs.launchpad.net/bugs/685105
Title:
enblend fails to blend
The enblend I'm running is compiled from the sources I've got on tuesday from
hg clone http://hg.code.sf.net/p/enblend/code enblend.hg
following those instructions:
http://wiki.panotools.org/Hugin_Compiling_Ubuntu#Building_Enblend
and @ this page:
Okey, so I've worked around that artefact problem
http://kaefert.is-a-geek.org/misc/hugin/360degree233pics_enblend-failure/artifacts-enblend-4-2/
by using gimp to cut out transperant holes where those artefacts where
and running enblend a second time with this holey panorama and those few
I ran into the same issue with the current enblend built from source.
How can I disable this graph-cut thing you mentioned bullinger?
** Attachment added: log.txt
https://bugs.launchpad.net/enblend/+bug/1193872/+attachment/3894452/+files/log.txt
--
You received this bug notification
For me it seems to be connected with trying to enblend pictures of different
lenses (wide-angle lens telephoto lens)
Though it does not happen with the first picture of the other lense, so I don't
know how to narrow it down to 2 pictures.
--
You received this bug notification because you are
update, okey, so I've (accidentially) found a way to get the failure to
show the bug with 2 pictures, though together they are 1,6gb in size:
Log-Output:
http://kaefert.is-a-geek.org/misc/hugin/enblend-bug-need-more-labels/re-enblend_2013-11-10_2205-08.log
command line that produced above
I can confirm that with a fresh enblend build from yesterday
(enblend-4.2.0-993) this bug is fixed! :)
Big thanks from me Mikolaj!
--
You received this bug notification because you are a member of Hugin
Developers, which is subscribed to Enblend.
https://bugs.launchpad.net/bugs/1193872
Title:
Public bug reported:
The GL-Preview window has on the tab Preview a checkbox that suggests
it could turn the grid of the preview of and on. For me it does nothing
as far as I can observe.
The 2011 version from the ubuntu repositories can turn off and on the
grid in the preview window as
thanks!
I've made a fresh hugin build after switching to the default branch, and I can
confirm that the GUI looks a little bit different and that the Grid switch
under the View menu does work as expected.
--
You received this bug notification because you are a member of Hugin
Developers, which
Public bug reported:
Hugins detection algorithm works well for a single row of pictures where
every picture can be easily alligned with the next row.
But for multi-row panoramas I often get a completely unusable mess,
because he tries to connect every picture with every other picture and
this
** Attachment added: And this is what it looks like when all control-points
but the ones between neighboring pictures are removed (links between the rows
are missing)
https://bugs.launchpad.net/hugin/+bug/1261215/+attachment/3929941/+files/Screenshot%20from%202013-12-15%2022%3A52%3A10.png
** Attachment added: This is what a panorama looks like with much to many
bogus control-points detected
https://bugs.launchpad.net/hugin/+bug/1261215/+attachment/3929938/+files/Screenshot%20from%202013-12-15%2022%3A26%3A19.png
--
You received this bug notification because you are a member
thanks for the response tmodes!
Is there somewhere a user-documentation of how to use these --multirow and or
--prealigned cpfind parameters to make cpfind know which pictures are neighbors
and which are not?
--
You received this bug notification because you are a member of Hugin
Developers,
Thanks! This --multirow feature seems to be used by default, and my
manual build seems to work quite well, though the new 2013.0 release
included in ubuntu 13.10 seems to have a bug somewhere that prevents
this feature from working correctly.
--
You received this bug notification because you are
For bigger panoramas I'm using a self-build enblend (since the enblend
build included in ubuntu fails with larger panoramas with out of memory
exceptions although memory is still available)
This newer enblend then will often give me black areas like those:
://wiki.panotools.org/Hugin_Compiling_Ubuntu
Previously this worked fine, but now I get those compile errors:
In file included from
/home/kaefert/src/enblend/enblend.hg/src/enblend.cc:178:0:
/home/kaefert/src/enblend/enblend.hg/src/common.h: In function ‘std::string
enblend
errors:
In file included from
/home/kaefert/src/enblend/enblend.hg/src/enblend.cc:178:0:
/home/kaefert/src/enblend/enblend.hg/src/common.h: In function ‘std::string
enblend::expandFilenameTemplate(const string, unsigned int, const string,
const string, unsigned int)’:
/home/kaefert/src
with current sources
Status in Enblend:
New
Bug description:
I'm trying to compile enblend, using this guide here:
http://wiki.panotools.org/Hugin_Compiling_Ubuntu
Previously this worked fine, but now I get those compile errors:
In file included from
/home/kaefert/src/enblend/enblend.hg/src
with changeset 1044
Status in Enblend:
New
Bug description:
I'm trying to compile enblend, using this guide here:
http://wiki.panotools.org/Hugin_Compiling_Ubuntu
Previously this worked fine, but now I get those compile errors:
In file included from
/home/kaefert/src/enblend/enblend.hg
to compile enblend with OpenCL support.
I've found this cmake switch:
-DENABLE_OPENCL:BOOL=ON
and this package in my repos:
nvidia-opencl-dev
Next I got an error from make package right at the beginning:
/bin/sh: 1: cannot create
/home/kaefert/src/enblend/enblend.build_1044/src/kernels
://wiki.panotools.org/Hugin_Compiling_Ubuntu
Previously this worked fine, but now I get those compile errors:
In file included from
/home/kaefert/src/enblend/enblend.hg/src/enblend.cc:178:0:
/home/kaefert/src/enblend/enblend.hg/src/common.h: In function ‘std::string
enblend::expandFilenameTemplate(const
to compile enblend with OpenCL support.
I've found this cmake switch:
-DENABLE_OPENCL:BOOL=ON
and this package in my repos:
nvidia-opencl-dev
Next I got an error from make package right at the beginning:
/bin/sh: 1: cannot create
/home/kaefert/src/enblend/enblend.build_1044/src/kernels
Public bug reported:
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
I've just written a mail to the vigra mailing list, and vigra's author told me
that
VIGRA is certainly able to work with more than 2^31 pixels when compiled with
a 64-bit compiler. We routinely do this.
He asked me Can you describe the problem more precisely?
Sadly I don't know how. All I know
Hmm, okey. so downloading and building
http://download.osgeo.org/libtiff/tiff-4.0.3.zip did work, and the new
build does seems to get used, since the output of enblend changed a
little bit, since those two lines get printed which did not get printed
before:
/home/kaefert/src/enblend
I've asked on the libtiff mailing list if they can help me, and this is
the response I got from user John:
libtiff4 will write a smalltiff file by default. Bigtiff is not a
compatible format, you need to specifically ask for it. Swap:
output = TIFFOpen( output_filename, w );
for
output =
Okey, so Ulli (a Vigra developer) wrote on the Vigra mailing-list that
he fixed / implemented bigtiff support:
I uploaded a fix to 'master' on github. BigTIFF now seems to work.
To enable bigtiff he said
you have to specify mode w8 in ImageExportInfo (C++) or writeImage()
(Python).
Does
just for traceability (especially since this bug seems to still be
present [I did not check it myself, just inferring from the bug status])
To explain my comments I've used a few links to pictures hosted on my own NAS
reachable through a dyn-dns domain, which is no longer available because they
I don't think that your solution fixes this issue.
Your panorama is 25132*12566 = 315.808.712 pixel in size.
The problem mentioned in the title is for panoramas with more than 2^31
= 2.147.483.648 pixels (nearly 7 times bigger than yours)
If somebody finds a a way to stich panoramas of that size
Well that's interesting, thanks for doing those tests!
I'll try to find my huge panorama from back then and try to retry the stiching
with a current nona 64bit build.
--
You received this bug notification because you are a member of Hugin
Developers, which is subscribed to Hugin.
I just installed hugin 2018.0.0-7 with enblend-enfuse 4.2-4 from the
default repositories on my Manjaro (Arch based) Laptop, and stiched an
wideangle 360° panorama from 32 images. Have 3 large black areas in
output.
I'm now trying the last mentioned workaround "--primary-seam-
generator=nft"
okey so it still randomly happens quite often that I get black areas on
stitching. One set that produces black areas though will produce the
same black areas when retrying. So I now usually work around this issue
by stitching in multiple steps, so split the original ~100 pictures in 5
groups â 20
update: the parameter "--primary-seam-generator=nft" does seem to make
the problem more rare, but right now I have a 360° panorama with a
targeted output size of 119448x6727 pixels which even though I tried
stiching 3 times always gave me black holes.
I'm currently trying the parameters @isaacq
Okey so the enblend that takes 5 minutes without the "--fine-mask"
parameter took 9 hours with it and gave worse results and without.
Now I instead built enblend myself using this
https://aur.archlinux.org/packages/enblend-hg/ with the corrected
repository from here:
46 matches
Mail list logo
