[Hugin-devs] [Bug 721136] Re: enblend creates an unexplainable black area.

2019-05-19 Thread kaefert
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 pictures and if one of them still produces black areas split
those in two again, repeat and join successful groups until finished.

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

Title:
  enblend creates an unexplainable black area.

Status in Enblend:
  Confirmed

Bug description:
  enblending   http://prive.bitwizard.nl/t80001.tif
  and  http://prive.bitwizard.nl/t80003.tif
  results in  http://prive.bitwizard.nl/t8a.tif

  I cannot say I expected that black triangle in the output. My enblend
  was pulled from hg this morning (no changes) and built without
  imagecache or openMP. (imagecache causes corruption of the output
  similar but different to this. )

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

___
Mailing list: https://launchpad.net/~hugin-devs
Post to : hugin-devs@lists.launchpad.net
Unsubscribe : https://launchpad.net/~hugin-devs
More help   : https://help.launchpad.net/ListHelp


[Hugin-devs] [Bug 721136] Re: enblend creates an unexplainable black area.

2019-04-19 Thread kaefert
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: http://hg.code.sf.net/p/enblend/code

And with this I now got a result without any black areas.

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

Title:
  enblend creates an unexplainable black area.

Status in Enblend:
  Confirmed

Bug description:
  enblending   http://prive.bitwizard.nl/t80001.tif
  and  http://prive.bitwizard.nl/t80003.tif
  results in  http://prive.bitwizard.nl/t8a.tif

  I cannot say I expected that black triangle in the output. My enblend
  was pulled from hg this morning (no changes) and built without
  imagecache or openMP. (imagecache causes corruption of the output
  similar but different to this. )

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

___
Mailing list: https://launchpad.net/~hugin-devs
Post to : hugin-devs@lists.launchpad.net
Unsubscribe : https://launchpad.net/~hugin-devs
More help   : https://help.launchpad.net/ListHelp


[Hugin-devs] [Bug 721136] Re: enblend creates an unexplainable black area.

2019-04-19 Thread kaefert
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 suggested: "--fine-mask
--primary-seam-generator=nearest-feature-transform" but that slows down
enblend a lot. Already running for over 6 hours.

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

Title:
  enblend creates an unexplainable black area.

Status in Enblend:
  Confirmed

Bug description:
  enblending   http://prive.bitwizard.nl/t80001.tif
  and  http://prive.bitwizard.nl/t80003.tif
  results in  http://prive.bitwizard.nl/t8a.tif

  I cannot say I expected that black triangle in the output. My enblend
  was pulled from hg this morning (no changes) and built without
  imagecache or openMP. (imagecache causes corruption of the output
  similar but different to this. )

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

___
Mailing list: https://launchpad.net/~hugin-devs
Post to : hugin-devs@lists.launchpad.net
Unsubscribe : https://launchpad.net/~hugin-devs
More help   : https://help.launchpad.net/ListHelp


[Hugin-devs] [Bug 721136] Re: enblend creates an unexplainable black area.

2019-04-06 Thread kaefert
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" after I reran the stitching with keeeping the
intermediary files.

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

Title:
  enblend creates an unexplainable black area.

Status in Enblend:
  Confirmed

Bug description:
  enblending   http://prive.bitwizard.nl/t80001.tif
  and  http://prive.bitwizard.nl/t80003.tif
  results in  http://prive.bitwizard.nl/t8a.tif

  I cannot say I expected that black triangle in the output. My enblend
  was pulled from hg this morning (no changes) and built without
  imagecache or openMP. (imagecache causes corruption of the output
  similar but different to this. )

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

___
Mailing list: https://launchpad.net/~hugin-devs
Post to : hugin-devs@lists.launchpad.net
Unsubscribe : https://launchpad.net/~hugin-devs
More help   : https://help.launchpad.net/ListHelp


[Hugin-devs] [Bug 1307023] Re: nona crashes with std::bad_alloc when input has more than 2^31 pixels

2016-09-03 Thread kaefert
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.
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=43,0,12
  
https://kaefert.is-a-geek.org/SaladoPlayer-1.3.5/?pano=koega_2013-11-27=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 : hugin-devs@lists.launchpad.net
Unsubscribe : https://launchpad.net/~hugin-devs
More help   : https://help.launchpad.net/ListHelp


[Hugin-devs] [Bug 1307023] Re: nona crashes with std::bad_alloc when input has more than 2^31 pixels

2016-09-03 Thread kaefert
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 or larger, I
would still be very interested in the solution.

-- 
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=43,0,12
  
https://kaefert.is-a-geek.org/SaladoPlayer-1.3.5/?pano=koega_2013-11-27=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 : hugin-devs@lists.launchpad.net
Unsubscribe : https://launchpad.net/~hugin-devs
More help   : https://help.launchpad.net/ListHelp


[Hugin-devs] [Bug 721136] Re: enblend creates an unexplainable black area.

2016-03-30 Thread kaefert
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 
canceled their free services. You can still find the images by replacing the 
domain kaefert.is-a-geek.org by either koega.no-ip.org or 
nas.koelbl15.wien.funkfeuer.at
So for example for the image in my comment above this one:
http://koega.no-ip.org/misc/hugin/enblend-black-areas/Screenshot%20from%202014-01-30%201918_40.jpg
http://nas.koelbl15.wien.funkfeuer.at/misc/hugin/enblend-black-areas/Screenshot%20from%202014-01-30%201918_40.jpg

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

Title:
  enblend creates an unexplainable black area.

Status in Enblend:
  Confirmed

Bug description:
  enblending   http://prive.bitwizard.nl/t80001.tif
  and  http://prive.bitwizard.nl/t80003.tif
  results in  http://prive.bitwizard.nl/t8a.tif

  I cannot say I expected that black triangle in the output. My enblend
  was pulled from hg this morning (no changes) and built without
  imagecache or openMP. (imagecache causes corruption of the output
  similar but different to this. )

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

___
Mailing list: https://launchpad.net/~hugin-devs
Post to : hugin-devs@lists.launchpad.net
Unsubscribe : https://launchpad.net/~hugin-devs
More help   : https://help.launchpad.net/ListHelp


[Hugin-devs] [Bug 1316967] Re: Maximum TIFF file size 4GB

2014-05-22 Thread kaefert
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 enblend do this? specifying mode w8? Or could you add it? It
would probably be best if there was a command line switch for enblend
that triggers this, since in many cases users would probably like to
have normal tiff files.

Kind Regards,

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

Title:
  Maximum TIFF file size 4GB

Status in Enblend:
  Triaged

Bug description:
  Hi there!

  After running for 2 days the enblend binary that I compiled myself
  from the enblend sources revision 1049 failed with this error:

  enblend: info: writing final output
  enblend: error: Maximum TIFF file size exceeded

  enblend: an exception occured
  enblend: 
  Postcondition violation!
  exportImage(): Unable to write TIFF data.
  (/build/buildd/libvigraimpex-1.9.0+dfsg/src/impex/tiff.cxx:811)

  enblend: info: remove invalid output image x1.tif
  ===

  I've used these parameters:  --compression=LZW --verbose
  --output=x1.tif

  The output pixel dimensions would have been 119598 * 17362 =
  2076460476 which is still well within the 2^31 pixel count limit =
  2147483648

  In the bug report #685105 I've mentioned that I've run into this problem 
before, and back then Jeff Hungerford (hungerf3) told me:
  If you are seeing that error, either the TIFF library you linked against 
doesn't support bigTIFF, or for some reason it decided to only use the old 
format.

  It would be very kind of you if you could guide my way how to compile
  enblend (and libtiff?) in a way that enblend will not fail when the
  output exceeds 4GB in file size.

  Or is there maybe a way to use another output format then tif to
  workaround this problem? (With Gimp I like to use png for images that
  are too big for 4GB tif, it has the same problem of failing to save
  4GB tiffs for me)

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

___
Mailing list: https://launchpad.net/~hugin-devs
Post to : hugin-devs@lists.launchpad.net
Unsubscribe : https://launchpad.net/~hugin-devs
More help   : https://help.launchpad.net/ListHelp


[Hugin-devs] [Bug 1316967] Re: Maximum TIFF file size 4GB

2014-05-09 Thread kaefert
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 = TIFFOpen( output_filename, w8 );

enblend will need to set this flag and I guess they'll need a bit of
UI to let people turn it on or off.

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

Title:
  Maximum TIFF file size 4GB

Status in Enblend:
  New

Bug description:
  Hi there!

  After running for 2 days the enblend binary that I compiled myself
  from the enblend sources revision 1049 failed with this error:

  enblend: info: writing final output
  enblend: error: Maximum TIFF file size exceeded

  enblend: an exception occured
  enblend: 
  Postcondition violation!
  exportImage(): Unable to write TIFF data.
  (/build/buildd/libvigraimpex-1.9.0+dfsg/src/impex/tiff.cxx:811)

  enblend: info: remove invalid output image x1.tif
  ===

  I've used these parameters:  --compression=LZW --verbose
  --output=x1.tif

  The output pixel dimensions would have been 119598 * 17362 =
  2076460476 which is still well within the 2^31 pixel count limit =
  2147483648

  In the bug report #685105 I've mentioned that I've run into this problem 
before, and back then Jeff Hungerford (hungerf3) told me:
  If you are seeing that error, either the TIFF library you linked against 
doesn't support bigTIFF, or for some reason it decided to only use the old 
format.

  It would be very kind of you if you could guide my way how to compile
  enblend (and libtiff?) in a way that enblend will not fail when the
  output exceeds 4GB in file size.

  Or is there maybe a way to use another output format then tif to
  workaround this problem? (With Gimp I like to use png for images that
  are too big for 4GB tif, it has the same problem of failing to save
  4GB tiffs for me)

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

___
Mailing list: https://launchpad.net/~hugin-devs
Post to : hugin-devs@lists.launchpad.net
Unsubscribe : https://launchpad.net/~hugin-devs
More help   : https://help.launchpad.net/ListHelp


[Hugin-devs] [Bug 1316967] Re: Maximum TIFF file size 4GB

2014-05-08 Thread kaefert
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/enblend.build_1049/bin/enblend: 
/usr/local/lib/libtiff.so.5: no version information available (required by 
/home/kaefert/src/enblend/enblend.build_1049/bin/enblend)
/home/kaefert/src/enblend/enblend.build_1049/bin/enblend: 
/usr/local/lib/libtiff.so.5: no version information available (required by 
/usr/lib/libvigraimpex.so.4)

Though sadly it still fails the same way:
enblend: error: Maximum TIFF file size exceeded

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

Title:
  Maximum TIFF file size 4GB

Status in Enblend:
  New

Bug description:
  Hi there!

  After running for 2 days the enblend binary that I compiled myself
  from the enblend sources revision 1049 failed with this error:

  enblend: info: writing final output
  enblend: error: Maximum TIFF file size exceeded

  enblend: an exception occured
  enblend: 
  Postcondition violation!
  exportImage(): Unable to write TIFF data.
  (/build/buildd/libvigraimpex-1.9.0+dfsg/src/impex/tiff.cxx:811)

  enblend: info: remove invalid output image x1.tif
  ===

  I've used these parameters:  --compression=LZW --verbose
  --output=x1.tif

  The output pixel dimensions would have been 119598 * 17362 =
  2076460476 which is still well within the 2^31 pixel count limit =
  2147483648

  In the bug report #685105 I've mentioned that I've run into this problem 
before, and back then Jeff Hungerford (hungerf3) told me:
  If you are seeing that error, either the TIFF library you linked against 
doesn't support bigTIFF, or for some reason it decided to only use the old 
format.

  It would be very kind of you if you could guide my way how to compile
  enblend (and libtiff?) in a way that enblend will not fail when the
  output exceeds 4GB in file size.

  Or is there maybe a way to use another output format then tif to
  workaround this problem? (With Gimp I like to use png for images that
  are too big for 4GB tif, it has the same problem of failing to save
  4GB tiffs for me)

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

___
Mailing list: https://launchpad.net/~hugin-devs
Post to : hugin-devs@lists.launchpad.net
Unsubscribe : https://launchpad.net/~hugin-devs
More help   : https://help.launchpad.net/ListHelp


[Hugin-devs] [Bug 1307023] Re: nona crashes with std::bad_alloc when input has more than 2^31 pixels

2014-04-13 Thread kaefert
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 is that nona and enblend fail quickly with 
out-of-memory exceptions while enough free memory is available.

-- 
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 - Panorama Tools GUI:
  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-10view=43,0,12
  
https://kaefert.is-a-geek.org/SaladoPlayer-1.3.5/?pano=koega_2013-11-27view=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 : hugin-devs@lists.launchpad.net
Unsubscribe : https://launchpad.net/~hugin-devs
More help   : https://help.launchpad.net/ListHelp


[Hugin-devs] [Bug 1307023] [NEW] nona crashes with std::bad_alloc when input has more than 2^31 pixels

2014-04-12 Thread kaefert
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 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-10view=43,0,12
https://kaefert.is-a-geek.org/SaladoPlayer-1.3.5/?pano=koega_2013-11-27view=44,-1,10

** Affects: hugin
 Importance: Undecided
 Status: New

-- 
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 - Panorama Tools GUI:
  New

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-10view=43,0,12
  
https://kaefert.is-a-geek.org/SaladoPlayer-1.3.5/?pano=koega_2013-11-27view=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 : hugin-devs@lists.launchpad.net
Unsubscribe : https://launchpad.net/~hugin-devs
More help   : https://help.launchpad.net/ListHelp


[Hugin-devs] [Bug 1305794] Re: OpenCL enabled build fails

2014-04-11 Thread kaefert
those are the versons of the OpenCL libraries installed on my system:

nvidia-opencl-dev 5.0.35-7ubuntu1 (saucy)
opencl-headers 1.2-2013.06.28-2 (saucy)
nvidia-libopencl1-331 331.67-0unbutu1~xedgers13.10.2 (saucy)

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

Title:
  OpenCL enabled build fails

Status in Enblend:
  New

Bug description:
  My newly built enblend binary printed a lot of those lines:
  enblend: info: no OpenCL support compiled into Enblend

  So I looked into how 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/distance_transform_fh.icl:
 Directory nonexistent

  So I created the directory manually, and now my compiling fails after 44% 
with a lot of lines like those:
  
opencl.cc:(.text._ZN3ocl12LazyFunctionINS_16SourceFilePolicyEE5buildERKSs[_ZN3ocl12LazyFunctionINS_16SourceFilePolicyEE5buildERKSs]+0x1d6):
 undefined reference to `clReleaseDevice'
  
opencl.cc:(.text._ZN3ocl12LazyFunctionINS_16SourceFilePolicyEE5buildERKSs[_ZN3ocl12LazyFunctionINS_16SourceFilePolicyEE5buildERKSs]+0x2d9):
 undefined reference to `clRetainDevice'

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

___
Mailing list: https://launchpad.net/~hugin-devs
Post to : hugin-devs@lists.launchpad.net
Unsubscribe : https://launchpad.net/~hugin-devs
More help   : https://help.launchpad.net/ListHelp


[Hugin-devs] [Bug 1305643] Re: enblend build errors with changeset 1044

2014-04-11 Thread kaefert
I can confirm that with the latest changset (1049) I can successfully compile 
enblend on my system.
A question on the side: what advantage would a newer boost version give me? 
(the one I currently have is simply the one delivered by my distro = mint16)

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

Title:
  enblend build errors with changeset 1044

Status in Enblend:
  Fix Committed

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/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/enblend/enblend.hg/src/common.h:732:25: error: 
‘BOOST_FALLTHROUGH’ was not declared in this scope
   BOOST_FALLTHROUGH;
   ^
  In file included from /home/kaefert/src/enblend/enblend.hg/src/mask.h:40:0,
   from /home/kaefert/src/enblend/enblend.hg/src/enblend.h:45,
   from /home/kaefert/src/enblend/enblend.hg/src/enblend.cc:180:
  /home/kaefert/src/enblend/enblend.hg/include/vigra_ext/fillpolygon.hxx: In 
function ‘void vigra_ext::detail::group_to_pairs(Iterator, Iterator, 
BackInsertIterator)’:
  
/home/kaefert/src/enblend/enblend.hg/include/vigra_ext/fillpolygon.hxx:255:21: 
error: ‘BOOST_FALLTHROUGH’ was not declared in this scope
   BOOST_FALLTHROUGH;
   ^
  make[2]: *** [src/CMakeFiles/enblend.dir/enblend.cc.o] Error 1
  make[1]: *** [src/CMakeFiles/enblend.dir/all] Error 2
  make: *** [all] Error 2

  Last time I had problems compiling enblend I could work around them by
  changing -DCMAKE_BUILD_TYPE=RelWithDebInfo into
  -DCMAKE_BUILD_TYPE=Debug - but this time that switch doesn't make any
  difference.

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

___
Mailing list: https://launchpad.net/~hugin-devs
Post to : hugin-devs@lists.launchpad.net
Unsubscribe : https://launchpad.net/~hugin-devs
More help   : https://help.launchpad.net/ListHelp


[Hugin-devs] [Bug 1305794] Re: OpenCL enabled build fails

2014-04-11 Thread kaefert
Okey, so I've been investigating some more on OpenCL
Now I've installed those additional packages:

nvidia-opencl-icd-331 331.67-0unbutu1~xedgers13.10.2 (saucy)
nvidia-331-uvm 331.67-0unbutu1~xedgers13.10.2 (saucy)

Now my clinfo output changed into this, which is still not what it should look 
like I guess.. :
[23501.842978] [ERROR]Cannot access secondary GPU - error: [XORG] (EE) Server 
terminated successfully (0). Closing log file.

[23501.843005] [ERROR]Aborting because fallback start is disabled.

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

Title:
  OpenCL enabled build fails

Status in Enblend:
  New

Bug description:
  My newly built enblend binary printed a lot of those lines:
  enblend: info: no OpenCL support compiled into Enblend

  So I looked into how 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/distance_transform_fh.icl:
 Directory nonexistent

  So I created the directory manually, and now my compiling fails after 44% 
with a lot of lines like those:
  
opencl.cc:(.text._ZN3ocl12LazyFunctionINS_16SourceFilePolicyEE5buildERKSs[_ZN3ocl12LazyFunctionINS_16SourceFilePolicyEE5buildERKSs]+0x1d6):
 undefined reference to `clReleaseDevice'
  
opencl.cc:(.text._ZN3ocl12LazyFunctionINS_16SourceFilePolicyEE5buildERKSs[_ZN3ocl12LazyFunctionINS_16SourceFilePolicyEE5buildERKSs]+0x2d9):
 undefined reference to `clRetainDevice'

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

___
Mailing list: https://launchpad.net/~hugin-devs
Post to : hugin-devs@lists.launchpad.net
Unsubscribe : https://launchpad.net/~hugin-devs
More help   : https://help.launchpad.net/ListHelp


[Hugin-devs] [Bug 1305643] Re: enblend build errors with current sources

2014-04-10 Thread kaefert
okey, so I've stepped back to changeset 1040 (randomly selected) and
with this compilation worked.

I still get some warnings like:
enfuse.h:122:45: warning: typedef ‘SrcPixelType’ locally defined but not used 
[-Wunused-local-typedefs]
But those sound like they can be ignored.

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

Title:
  enblend build errors 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/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/enblend/enblend.hg/src/common.h:732:25: error: 
‘BOOST_FALLTHROUGH’ was not declared in this scope
   BOOST_FALLTHROUGH;
   ^
  In file included from /home/kaefert/src/enblend/enblend.hg/src/mask.h:40:0,
   from /home/kaefert/src/enblend/enblend.hg/src/enblend.h:45,
   from /home/kaefert/src/enblend/enblend.hg/src/enblend.cc:180:
  /home/kaefert/src/enblend/enblend.hg/include/vigra_ext/fillpolygon.hxx: In 
function ‘void vigra_ext::detail::group_to_pairs(Iterator, Iterator, 
BackInsertIterator)’:
  
/home/kaefert/src/enblend/enblend.hg/include/vigra_ext/fillpolygon.hxx:255:21: 
error: ‘BOOST_FALLTHROUGH’ was not declared in this scope
   BOOST_FALLTHROUGH;
   ^
  make[2]: *** [src/CMakeFiles/enblend.dir/enblend.cc.o] Error 1
  make[1]: *** [src/CMakeFiles/enblend.dir/all] Error 2
  make: *** [all] Error 2

  Last time I had problems compiling enblend I could work around them by
  changing -DCMAKE_BUILD_TYPE=RelWithDebInfo into
  -DCMAKE_BUILD_TYPE=Debug - but this time that switch doesn't make any
  difference.

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

___
Mailing list: https://launchpad.net/~hugin-devs
Post to : hugin-devs@lists.launchpad.net
Unsubscribe : https://launchpad.net/~hugin-devs
More help   : https://help.launchpad.net/ListHelp


[Hugin-devs] [Bug 1305643] Re: enblend build errors with current sources

2014-04-10 Thread kaefert
the most recent changeset with which I observed the issue is: 1044:64255abdea39
So it must be caused by something contained in the changesets between 
(including) 1044 and 1041

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

Title:
  enblend build errors 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/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/enblend/enblend.hg/src/common.h:732:25: error: 
‘BOOST_FALLTHROUGH’ was not declared in this scope
   BOOST_FALLTHROUGH;
   ^
  In file included from /home/kaefert/src/enblend/enblend.hg/src/mask.h:40:0,
   from /home/kaefert/src/enblend/enblend.hg/src/enblend.h:45,
   from /home/kaefert/src/enblend/enblend.hg/src/enblend.cc:180:
  /home/kaefert/src/enblend/enblend.hg/include/vigra_ext/fillpolygon.hxx: In 
function ‘void vigra_ext::detail::group_to_pairs(Iterator, Iterator, 
BackInsertIterator)’:
  
/home/kaefert/src/enblend/enblend.hg/include/vigra_ext/fillpolygon.hxx:255:21: 
error: ‘BOOST_FALLTHROUGH’ was not declared in this scope
   BOOST_FALLTHROUGH;
   ^
  make[2]: *** [src/CMakeFiles/enblend.dir/enblend.cc.o] Error 1
  make[1]: *** [src/CMakeFiles/enblend.dir/all] Error 2
  make: *** [all] Error 2

  Last time I had problems compiling enblend I could work around them by
  changing -DCMAKE_BUILD_TYPE=RelWithDebInfo into
  -DCMAKE_BUILD_TYPE=Debug - but this time that switch doesn't make any
  difference.

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

___
Mailing list: https://launchpad.net/~hugin-devs
Post to : hugin-devs@lists.launchpad.net
Unsubscribe : https://launchpad.net/~hugin-devs
More help   : https://help.launchpad.net/ListHelp


[Hugin-devs] [Bug 1305643] Re: enblend build errors with current sources

2014-04-10 Thread kaefert
okey, so its definitely the last changeset 1044, with 1043 I can compile
enblend just like with 1040

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

Title:
  enblend build errors 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/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/enblend/enblend.hg/src/common.h:732:25: error: 
‘BOOST_FALLTHROUGH’ was not declared in this scope
   BOOST_FALLTHROUGH;
   ^
  In file included from /home/kaefert/src/enblend/enblend.hg/src/mask.h:40:0,
   from /home/kaefert/src/enblend/enblend.hg/src/enblend.h:45,
   from /home/kaefert/src/enblend/enblend.hg/src/enblend.cc:180:
  /home/kaefert/src/enblend/enblend.hg/include/vigra_ext/fillpolygon.hxx: In 
function ‘void vigra_ext::detail::group_to_pairs(Iterator, Iterator, 
BackInsertIterator)’:
  
/home/kaefert/src/enblend/enblend.hg/include/vigra_ext/fillpolygon.hxx:255:21: 
error: ‘BOOST_FALLTHROUGH’ was not declared in this scope
   BOOST_FALLTHROUGH;
   ^
  make[2]: *** [src/CMakeFiles/enblend.dir/enblend.cc.o] Error 1
  make[1]: *** [src/CMakeFiles/enblend.dir/all] Error 2
  make: *** [all] Error 2

  Last time I had problems compiling enblend I could work around them by
  changing -DCMAKE_BUILD_TYPE=RelWithDebInfo into
  -DCMAKE_BUILD_TYPE=Debug - but this time that switch doesn't make any
  difference.

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

___
Mailing list: https://launchpad.net/~hugin-devs
Post to : hugin-devs@lists.launchpad.net
Unsubscribe : https://launchpad.net/~hugin-devs
More help   : https://help.launchpad.net/ListHelp


[Hugin-devs] [Bug 1305643] Re: enblend build errors with changeset 1044

2014-04-10 Thread kaefert
** Summary changed:

- enblend build errors with current sources
+ enblend build errors with changeset 1044

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

Title:
  enblend build errors 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/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/enblend/enblend.hg/src/common.h:732:25: error: 
‘BOOST_FALLTHROUGH’ was not declared in this scope
   BOOST_FALLTHROUGH;
   ^
  In file included from /home/kaefert/src/enblend/enblend.hg/src/mask.h:40:0,
   from /home/kaefert/src/enblend/enblend.hg/src/enblend.h:45,
   from /home/kaefert/src/enblend/enblend.hg/src/enblend.cc:180:
  /home/kaefert/src/enblend/enblend.hg/include/vigra_ext/fillpolygon.hxx: In 
function ‘void vigra_ext::detail::group_to_pairs(Iterator, Iterator, 
BackInsertIterator)’:
  
/home/kaefert/src/enblend/enblend.hg/include/vigra_ext/fillpolygon.hxx:255:21: 
error: ‘BOOST_FALLTHROUGH’ was not declared in this scope
   BOOST_FALLTHROUGH;
   ^
  make[2]: *** [src/CMakeFiles/enblend.dir/enblend.cc.o] Error 1
  make[1]: *** [src/CMakeFiles/enblend.dir/all] Error 2
  make: *** [all] Error 2

  Last time I had problems compiling enblend I could work around them by
  changing -DCMAKE_BUILD_TYPE=RelWithDebInfo into
  -DCMAKE_BUILD_TYPE=Debug - but this time that switch doesn't make any
  difference.

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

___
Mailing list: https://launchpad.net/~hugin-devs
Post to : hugin-devs@lists.launchpad.net
Unsubscribe : https://launchpad.net/~hugin-devs
More help   : https://help.launchpad.net/ListHelp


[Hugin-devs] [Bug 721136] Re: enblend creates an unexplainable black area.

2014-01-30 Thread kaefert
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:
http://kaefert.is-a-geek.org/misc/hugin/enblend-black-areas/Screenshot%20from%202014-01-30%201918_40.jpg

The only workaround that I have at the moment is to cut out the bad
parts with gimp, copy the exif tags from enblend's output to the cut
version created with gimp and enblend the appropiate nona-output images
again with this cut variant.

Is there something I could do to help getting this problem fixed?
(besides working my way through the huge enblend codebase myself)

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

Title:
  enblend creates an unexplainable black area.

Status in Enblend:
  Confirmed

Bug description:
  enblending   http://prive.bitwizard.nl/t80001.tif
  and  http://prive.bitwizard.nl/t80003.tif
  results in  http://prive.bitwizard.nl/t8a.tif

  I cannot say I expected that black triangle in the output. My enblend
  was pulled from hg this morning (no changes) and built without
  imagecache or openMP. (imagecache causes corruption of the output
  similar but different to this. )

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

___
Mailing list: https://launchpad.net/~hugin-devs
Post to : hugin-devs@lists.launchpad.net
Unsubscribe : https://launchpad.net/~hugin-devs
More help   : https://help.launchpad.net/ListHelp


[Hugin-devs] [Bug 1261215] Re: missing feature: Control-point detector: allow user to define rows and columns

2013-12-16 Thread kaefert
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, which is subscribed to Hugin.
https://bugs.launchpad.net/bugs/1261215

Title:
  missing feature: Control-point detector: allow user to define rows and
  columns

Status in Hugin - Panorama Tools GUI:
  Won't Fix

Bug description:
  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 creates a huge amount of false positives that is simply much to
  much work to clean up manually after him.

  So what I need is to define the grid of rows and columns for the
  control-point detector so that he will only try to create control-
  points between neighboring pictures, to reduce the false-positive
  control-points.

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

___
Mailing list: https://launchpad.net/~hugin-devs
Post to : hugin-devs@lists.launchpad.net
Unsubscribe : https://launchpad.net/~hugin-devs
More help   : https://help.launchpad.net/ListHelp


[Hugin-devs] [Bug 1261215] Re: missing feature: Control-point detector: allow user to define rows and columns

2013-12-16 Thread kaefert
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 a member of Hugin
Developers, which is subscribed to Hugin.
https://bugs.launchpad.net/bugs/1261215

Title:
  missing feature: Control-point detector: allow user to define rows and
  columns

Status in Hugin - Panorama Tools GUI:
  Won't Fix

Bug description:
  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 creates a huge amount of false positives that is simply much to
  much work to clean up manually after him.

  So what I need is to define the grid of rows and columns for the
  control-point detector so that he will only try to create control-
  points between neighboring pictures, to reduce the false-positive
  control-points.

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

___
Mailing list: https://launchpad.net/~hugin-devs
Post to : hugin-devs@lists.launchpad.net
Unsubscribe : https://launchpad.net/~hugin-devs
More help   : https://help.launchpad.net/ListHelp


[Hugin-devs] [Bug 1261215] [NEW] missing feature: Control-point detector: allow user to define rows and columns

2013-12-15 Thread kaefert
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 creates a huge amount of false positives that is simply much to
much work to clean up manually after him.

So what I need is to define the grid of rows and columns for the
control-point detector so that he will only try to create control-points
between neighboring pictures, to reduce the false-positive control-
points.

** Affects: hugin
 Importance: Undecided
 Status: New

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

Title:
  missing feature: Control-point detector: allow user to define rows and
  columns

Status in Hugin - Panorama Tools GUI:
  New

Bug description:
  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 creates a huge amount of false positives that is simply much to
  much work to clean up manually after him.

  So what I need is to define the grid of rows and columns for the
  control-point detector so that he will only try to create control-
  points between neighboring pictures, to reduce the false-positive
  control-points.

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

___
Mailing list: https://launchpad.net/~hugin-devs
Post to : hugin-devs@lists.launchpad.net
Unsubscribe : https://launchpad.net/~hugin-devs
More help   : https://help.launchpad.net/ListHelp


[Hugin-devs] [Bug 1261215] Re: missing feature: Control-point detector: allow user to define rows and columns

2013-12-15 Thread kaefert
** 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

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

Title:
  missing feature: Control-point detector: allow user to define rows and
  columns

Status in Hugin - Panorama Tools GUI:
  New

Bug description:
  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 creates a huge amount of false positives that is simply much to
  much work to clean up manually after him.

  So what I need is to define the grid of rows and columns for the
  control-point detector so that he will only try to create control-
  points between neighboring pictures, to reduce the false-positive
  control-points.

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

___
Mailing list: https://launchpad.net/~hugin-devs
Post to : hugin-devs@lists.launchpad.net
Unsubscribe : https://launchpad.net/~hugin-devs
More help   : https://help.launchpad.net/ListHelp


[Hugin-devs] [Bug 1261215] Re: missing feature: Control-point detector: allow user to define rows and columns

2013-12-15 Thread kaefert
** 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 of Hugin
Developers, which is subscribed to Hugin.
https://bugs.launchpad.net/bugs/1261215

Title:
  missing feature: Control-point detector: allow user to define rows and
  columns

Status in Hugin - Panorama Tools GUI:
  New

Bug description:
  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 creates a huge amount of false positives that is simply much to
  much work to clean up manually after him.

  So what I need is to define the grid of rows and columns for the
  control-point detector so that he will only try to create control-
  points between neighboring pictures, to reduce the false-positive
  control-points.

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

___
Mailing list: https://launchpad.net/~hugin-devs
Post to : hugin-devs@lists.launchpad.net
Unsubscribe : https://launchpad.net/~hugin-devs
More help   : https://help.launchpad.net/ListHelp


[Hugin-devs] [Bug 1258972] Re: preview grid check-box is ignored, grid always shows (2013.0 built from source)

2013-12-14 Thread kaefert
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 is subscribed to Hugin.
https://bugs.launchpad.net/bugs/1258972

Title:
  preview grid check-box is ignored, grid always shows (2013.0 built
  from source)

Status in Hugin - Panorama Tools GUI:
  Fix Committed

Bug description:
  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 expected.

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

___
Mailing list: https://launchpad.net/~hugin-devs
Post to : hugin-devs@lists.launchpad.net
Unsubscribe : https://launchpad.net/~hugin-devs
More help   : https://help.launchpad.net/ListHelp


[Hugin-devs] [Bug 1258972] [NEW] preview grid check-box is ignored, grid always shows (2013.0 built from source)

2013-12-08 Thread kaefert
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 expected.

** Affects: hugin
 Importance: Undecided
 Status: New

** Attachment added: 
hugin-preview-Screenshot_unchecked-grid-checkbox_grid-still-shows.png
   
https://bugs.launchpad.net/bugs/1258972/+attachment/3925445/+files/hugin-preview-Screenshot_unchecked-grid-checkbox_grid-still-shows.png

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

Title:
  preview grid check-box is ignored, grid always shows (2013.0 built
  from source)

Status in Hugin - Panorama Tools GUI:
  New

Bug description:
  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 expected.

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

___
Mailing list: https://launchpad.net/~hugin-devs
Post to : hugin-devs@lists.launchpad.net
Unsubscribe : https://launchpad.net/~hugin-devs
More help   : https://help.launchpad.net/ListHelp


[Hugin-devs] [Bug 1193872] Re: Invariant violation! connected components: Need more labels than can be represented in the destination type.

2013-12-04 Thread kaefert
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:
  Invariant violation! connected components: Need more labels than can
  be represented in the destination type.

Status in Enblend:
  Fix Committed

Bug description:
  See attached file

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

___
Mailing list: https://launchpad.net/~hugin-devs
Post to : hugin-devs@lists.launchpad.net
Unsubscribe : https://launchpad.net/~hugin-devs
More help   : https://help.launchpad.net/ListHelp


[Hugin-devs] [Bug 1193872] Re: Invariant violation! connected components: Need more labels than can be represented in the destination type.

2013-11-10 Thread kaefert
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 log-file:
http://kaefert.is-a-geek.org/misc/hugin/enblend-bug-need-more-labels/re-enblend.sh

pictures:
http://kaefert.is-a-geek.org/misc/hugin/enblend-bug-need-more-labels/2013-11-10_2019.tif
http://kaefert.is-a-geek.org/misc/hugin/enblend-bug-need-more-labels/2013-11-10_20190001_cut.tif

with enblend 4.0 which is the default included in ubuntu 13.04 does not have 
this bug, but also fails to enblend those two pictures since it the bug that 
tiff compression doesn't work, and the missing feature to support bigtiff 
(tiffs bigger than 4gb), heres the log enblend 4.0 produces:
http://kaefert.is-a-geek.org/misc/hugin/enblend-bug-need-more-labels/enblend-4-0_re-enblend_2013-11-10_2156-18.log

-- 
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:
  Invariant violation! connected components: Need more labels than can
  be represented in the destination type.

Status in Enblend:
  In Progress

Bug description:
  See attached file

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

___
Mailing list: https://launchpad.net/~hugin-devs
Post to : hugin-devs@lists.launchpad.net
Unsubscribe : https://launchpad.net/~hugin-devs
More help   : https://help.launchpad.net/ListHelp


[Hugin-devs] [Bug 1193872] Re: Invariant violation! connected components: Need more labels than can be represented in the destination type.

2013-11-09 Thread kaefert
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 a member of Hugin
Developers, which is subscribed to Enblend.
https://bugs.launchpad.net/bugs/1193872

Title:
  Invariant violation! connected components: Need more labels than can
  be represented in the destination type.

Status in Enblend:
  In Progress

Bug description:
  See attached file

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

___
Mailing list: https://launchpad.net/~hugin-devs
Post to : hugin-devs@lists.launchpad.net
Unsubscribe : https://launchpad.net/~hugin-devs
More help   : https://help.launchpad.net/ListHelp


[Hugin-devs] [Bug 1193872] Re: Invariant violation! connected components: Need more labels than can be represented in the destination type.

2013-10-29 Thread kaefert
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 because you are a member of Hugin
Developers, which is subscribed to Enblend.
https://bugs.launchpad.net/bugs/1193872

Title:
  Invariant violation! connected components: Need more labels than can
  be represented in the destination type.

Status in Enblend:
  New

Bug description:
  See attached file

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

___
Mailing list: https://launchpad.net/~hugin-devs
Post to : hugin-devs@lists.launchpad.net
Unsubscribe : https://launchpad.net/~hugin-devs
More help   : https://help.launchpad.net/ListHelp


[Hugin-devs] [Bug 685105] Re: enblend fails to blend large pano

2013-10-28 Thread kaefert
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
pictures produced by nona to fill those holes as input.

-- 
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 large pano

Status in Enblend:
  Confirmed

Bug description:
  Enblend failed with:

  enblend --compression=LZW -m 1200 -w -f135659x3947+0+1091 -o pano8110_l.tif 

  ...
  enblend: info: loading next image: pano8110_l.tif 1/1
  enblend: out of memory
  enblend: std::bad_alloc

  This is a simple 0.5Gpixel panorama I shot. And agreed, Hugin did warn
  me that it might take a lot of memory.

  The thing is: There is no other tool to stitch this with, so I'll have to 
make do with hugin and its toolset
  I thought there was an imagecache that would swap parts of images to disk...

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

___
Mailing list: https://launchpad.net/~hugin-devs
Post to : hugin-devs@lists.launchpad.net
Unsubscribe : https://launchpad.net/~hugin-devs
More help   : https://help.launchpad.net/ListHelp


[Hugin-devs] [Bug 685105] Re: enblend fails to blend large pano

2013-10-18 Thread kaefert
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 see might be related to this bug:
https://bugs.launchpad.net/enblend/+bug/721136

Though I do not understand what @rew (r-e-wolff) said about disk
swapping of images -- Is this the same as the this imagecache feature
and does this still exist in the latest versions of enblend? From what
you guys posted I thought it was a discontinued feature, but from what I
read over at https://bugs.launchpad.net/enblend/+bug/721136 it sounds
like my blackish artefacts stem from a bug in this imagecache thingy.

-- 
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 large pano

Status in Enblend:
  Confirmed

Bug description:
  Enblend failed with:

  enblend --compression=LZW -m 1200 -w -f135659x3947+0+1091 -o pano8110_l.tif 

  ...
  enblend: info: loading next image: pano8110_l.tif 1/1
  enblend: out of memory
  enblend: std::bad_alloc

  This is a simple 0.5Gpixel panorama I shot. And agreed, Hugin did warn
  me that it might take a lot of memory.

  The thing is: There is no other tool to stitch this with, so I'll have to 
make do with hugin and its toolset
  I thought there was an imagecache that would swap parts of images to disk...

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

___
Mailing list: https://launchpad.net/~hugin-devs
Post to : hugin-devs@lists.launchpad.net
Unsubscribe : https://launchpad.net/~hugin-devs
More help   : https://help.launchpad.net/ListHelp


[Hugin-devs] [Bug 685105] Re: enblend fails to blend large pano

2013-10-18 Thread kaefert
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 panorma on my 
Asus Zenbook UX32VD. (Intel i7-3517U @ 1.90GHz - Dual core, Swap Disk was a 
100GB partition on my Transcend SSD320 256GB)

-- 
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 large pano

Status in Enblend:
  Confirmed

Bug description:
  Enblend failed with:

  enblend --compression=LZW -m 1200 -w -f135659x3947+0+1091 -o pano8110_l.tif 

  ...
  enblend: info: loading next image: pano8110_l.tif 1/1
  enblend: out of memory
  enblend: std::bad_alloc

  This is a simple 0.5Gpixel panorama I shot. And agreed, Hugin did warn
  me that it might take a lot of memory.

  The thing is: There is no other tool to stitch this with, so I'll have to 
make do with hugin and its toolset
  I thought there was an imagecache that would swap parts of images to disk...

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

___
Mailing list: https://launchpad.net/~hugin-devs
Post to : hugin-devs@lists.launchpad.net
Unsubscribe : https://launchpad.net/~hugin-devs
More help   : https://help.launchpad.net/ListHelp


[Hugin-devs] [Bug 685105] Re: enblend fails to blend large pano

2013-10-18 Thread kaefert
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 large pano

Status in Enblend:
  Confirmed

Bug description:
  Enblend failed with:

  enblend --compression=LZW -m 1200 -w -f135659x3947+0+1091 -o pano8110_l.tif 

  ...
  enblend: info: loading next image: pano8110_l.tif 1/1
  enblend: out of memory
  enblend: std::bad_alloc

  This is a simple 0.5Gpixel panorama I shot. And agreed, Hugin did warn
  me that it might take a lot of memory.

  The thing is: There is no other tool to stitch this with, so I'll have to 
make do with hugin and its toolset
  I thought there was an imagecache that would swap parts of images to disk...

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

___
Mailing list: https://launchpad.net/~hugin-devs
Post to : hugin-devs@lists.launchpad.net
Unsubscribe : https://launchpad.net/~hugin-devs
More help   : https://help.launchpad.net/ListHelp


[Hugin-devs] [Bug 685105] Re: enblend fails to blend large pano

2013-10-18 Thread kaefert
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:
http://hg.code.sf.net/p/enblend/code/shortlog/27edd6c31bd2
I found those changesets:
Sun, 09 Dec 2012 09:55:26 +0100 Chris   Disable image cache.
Sun, 09 Dec 2012 09:54:35 +0100 Chris   Make the disable ImageCache 
configuration the default.

so I think my enblend should not use this ImageCache feature. Also if it
did, why would it use 52 gigabytes of memory?

-- 
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 large pano

Status in Enblend:
  Confirmed

Bug description:
  Enblend failed with:

  enblend --compression=LZW -m 1200 -w -f135659x3947+0+1091 -o pano8110_l.tif 

  ...
  enblend: info: loading next image: pano8110_l.tif 1/1
  enblend: out of memory
  enblend: std::bad_alloc

  This is a simple 0.5Gpixel panorama I shot. And agreed, Hugin did warn
  me that it might take a lot of memory.

  The thing is: There is no other tool to stitch this with, so I'll have to 
make do with hugin and its toolset
  I thought there was an imagecache that would swap parts of images to disk...

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

___
Mailing list: https://launchpad.net/~hugin-devs
Post to : hugin-devs@lists.launchpad.net
Unsubscribe : https://launchpad.net/~hugin-devs
More help   : https://help.launchpad.net/ListHelp


[Hugin-devs] [Bug 685105] Re: enblend fails to blend large pano

2013-10-17 Thread kaefert
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 than 2**31
pixels will fail within minutes, and since Christoph said that this is
simply not possible I'm gonna let that one go. Though why someone would
address pixels with a signed integer type still puzzles me...

So I've settled to trying to achieve to create a panorama of the size
240.000 x 8.292 = 1.990.080.000 pixels, which is smaller than 2^31 =
2.147.483.648

My first try failed after a few hours when trying to enblend picture 66
of 229 - with an out of memory exception. Though unlike with previous
memory exceptions this time the memory  swap space truly was
completly full. (10GB RAM + 20GB Swap). So I've decided to make my swap
partition a little bigger (100GB) and now enblend is already running for
a little over 24 hours and is currently enblending picture 140 of 229
and the biggest memory usage I saw until now was 10GB RAM + 39GB swap =
49GB total.

Another Problem I've got is the introduction of artefacts by enblend. 
With the self-compiled enblend version specified above I've created two 
panoramas yet - one 100.000 x 3.455 pixels, and one with 130.000 x 4.492 
pixels, and both show artifacts like those
http://kaefert.is-a-geek.org/misc/hugin/360degree233pics_enblend-failure/artifacts-enblend-4-2/
though the bigger version has more of them, and more severe ones.

With the default Ubuntu 13.04 enblend package 4.0+dfsg-4ubuntu3 I've
tried a lot of different sizes, and the biggest one without artefacts
was 86.000 x 2.881 pixels, the biggest one that did not fail to enblend
was 135.000 x 7.191. The artifacts that this old enblend version
introduced into the panorama where hundreds of 1 pixel thick lines that
where black, or dark gray or sometimes also nearly invisible because of
nearly the same color as the panorama at that segment. The bigger the
panorama the more of those lines where introduced.

-- 
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 large pano

Status in Enblend:
  Confirmed

Bug description:
  Enblend failed with:

  enblend --compression=LZW -m 1200 -w -f135659x3947+0+1091 -o pano8110_l.tif 

  ...
  enblend: info: loading next image: pano8110_l.tif 1/1
  enblend: out of memory
  enblend: std::bad_alloc

  This is a simple 0.5Gpixel panorama I shot. And agreed, Hugin did warn
  me that it might take a lot of memory.

  The thing is: There is no other tool to stitch this with, so I'll have to 
make do with hugin and its toolset
  I thought there was an imagecache that would swap parts of images to disk...

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

___
Mailing list: https://launchpad.net/~hugin-devs
Post to : hugin-devs@lists.launchpad.net
Unsubscribe : https://launchpad.net/~hugin-devs
More help   : https://help.launchpad.net/ListHelp


[Hugin-devs] [Bug 685105] Re: enblend fails to blend large pano

2013-10-10 Thread kaefert
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 with the dimensions of 14x3791 (or 14x7858 before the crop 
configured in hugin if that matters) and enblend failed with the same out of 
memory error again.
I've put the project and the compressed intermediate tif files here:
http://kaefert.is-a-geek.org/misc/hugin/360degree233pics_enblend-failure/2013-10-10_2258_140k_enblend-failed/
The original jpgs can still be found in the parent folder, directory listing is 
activated so you can navigate there.

-- 
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 large pano

Status in Enblend:
  Confirmed

Bug description:
  Enblend failed with:

  enblend --compression=LZW -m 1200 -w -f135659x3947+0+1091 -o pano8110_l.tif 

  ...
  enblend: info: loading next image: pano8110_l.tif 1/1
  enblend: out of memory
  enblend: std::bad_alloc

  This is a simple 0.5Gpixel panorama I shot. And agreed, Hugin did warn
  me that it might take a lot of memory.

  The thing is: There is no other tool to stitch this with, so I'll have to 
make do with hugin and its toolset
  I thought there was an imagecache that would swap parts of images to disk...

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

___
Mailing list: https://launchpad.net/~hugin-devs
Post to : hugin-devs@lists.launchpad.net
Unsubscribe : https://launchpad.net/~hugin-devs
More help   : https://help.launchpad.net/ListHelp


[Hugin-devs] [Bug 685105] Re: enblend fails to blend large pano

2013-10-02 Thread kaefert
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 that I was able to 
successfully stich together with hugin 2011.4.0.cf9be9344356 (included in the 
Ubuntu 13.04 repos) resulted in a tif file with the dimensions 91119x3771
4294967295 = 2^32-1
0343609749 = 91119*3771
1374438996 = 91119*3771*4
multiplied by for (90*4=360 degrees) this still leaves a lot of space before it 
could hit INT_MAX pixels.

If I could make a wish it would be a way to be able to have the zoom levels 
that I've got in the jpgs linked from within this panorama but directly within 
the SaladoPlayer.
http://kaefert.is-a-geek.org/SaladoPlayer-1.3.5/

Another thing that would be great for that purpose was if I could
combine pictures of different zoom levels into a panroama with hugin.

Another problem: With hugin 2012 the assistant finds a lot of wrong
control points between pictures that don't overlap - Is there some way
to configure this assistant to only search for controlpoints within
neighboring pictures - like it seems like the 2011 hugin does?

-- 
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 large pano

Status in Enblend:
  Confirmed

Bug description:
  Enblend failed with:

  enblend --compression=LZW -m 1200 -w -f135659x3947+0+1091 -o pano8110_l.tif 

  ...
  enblend: info: loading next image: pano8110_l.tif 1/1
  enblend: out of memory
  enblend: std::bad_alloc

  This is a simple 0.5Gpixel panorama I shot. And agreed, Hugin did warn
  me that it might take a lot of memory.

  The thing is: There is no other tool to stitch this with, so I'll have to 
make do with hugin and its toolset
  I thought there was an imagecache that would swap parts of images to disk...

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

___
Mailing list: https://launchpad.net/~hugin-devs
Post to : hugin-devs@lists.launchpad.net
Unsubscribe : https://launchpad.net/~hugin-devs
More help   : https://help.launchpad.net/ListHelp


[Hugin-devs] [Bug 685105] Re: enblend fails to blend large pano

2013-09-07 Thread kaefert
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 fails really fast (with the same memory error) - 
even before it prints the first 
enblend: info: loading next image: line. Memory Usage doesn't spike when this 
happens, so no idea how he manages to produce an out of memory exception in 
this case.

Now I compiled 4.1.1 with the default options. This failed after 7 1/2
hours (the last nano tiff got a timestamp of 0:44, crash happened at
8:15)

And with this the memory usage does spike, but the SWAP space still was only 
half filled (9,7GB filled out of 19,94GiB available)
Here's the story with commented dstat output:
http://pastebin.com/raw.php?i=7AATfsXz

-- 
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 large pano

Status in Enblend:
  Confirmed

Bug description:
  Enblend failed with:

  enblend --compression=LZW -m 1200 -w -f135659x3947+0+1091 -o pano8110_l.tif 

  ...
  enblend: info: loading next image: pano8110_l.tif 1/1
  enblend: out of memory
  enblend: std::bad_alloc

  This is a simple 0.5Gpixel panorama I shot. And agreed, Hugin did warn
  me that it might take a lot of memory.

  The thing is: There is no other tool to stitch this with, so I'll have to 
make do with hugin and its toolset
  I thought there was an imagecache that would swap parts of images to disk...

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

___
Mailing list: https://launchpad.net/~hugin-devs
Post to : hugin-devs@lists.launchpad.net
Unsubscribe : https://launchpad.net/~hugin-devs
More help   : https://help.launchpad.net/ListHelp


[Hugin-devs] [Bug 685105] Re: enblend fails to blend large pano

2013-09-07 Thread kaefert
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 close to finishing
the panorama this one time where he failed after loading picture nr.
227)

All 233 jpgs together have a size of 464,6MB - If you want I'll put them
on my webserver like that or if downloading for a few hours is too much
I can use your reducing script first.

This is my detailed enblend version info of the precompiled package from my 
distro (ubuntu 13.04)
http://pastebin.com/SLMtrHHy
This one worked best so far, meaning it gave me the most
enblend: info: loading next image: name0number.tif 1/1
lines before failing.

-- 
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 large pano

Status in Enblend:
  Confirmed

Bug description:
  Enblend failed with:

  enblend --compression=LZW -m 1200 -w -f135659x3947+0+1091 -o pano8110_l.tif 

  ...
  enblend: info: loading next image: pano8110_l.tif 1/1
  enblend: out of memory
  enblend: std::bad_alloc

  This is a simple 0.5Gpixel panorama I shot. And agreed, Hugin did warn
  me that it might take a lot of memory.

  The thing is: There is no other tool to stitch this with, so I'll have to 
make do with hugin and its toolset
  I thought there was an imagecache that would swap parts of images to disk...

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

___
Mailing list: https://launchpad.net/~hugin-devs
Post to : hugin-devs@lists.launchpad.net
Unsubscribe : https://launchpad.net/~hugin-devs
More help   : https://help.launchpad.net/ListHelp


[Hugin-devs] [Bug 685105] Re: enblend fails to blend large pano

2013-09-07 Thread kaefert
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 NAS at home runs with a speed of 23kb/s - so will
be finished in 5 hours... (It would probably be faster to driver home,
transfer it via my wifi at home and drive back here, but that would cost
a lot of gas and therefore money ;) )

-- 
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 large pano

Status in Enblend:
  Confirmed

Bug description:
  Enblend failed with:

  enblend --compression=LZW -m 1200 -w -f135659x3947+0+1091 -o pano8110_l.tif 

  ...
  enblend: info: loading next image: pano8110_l.tif 1/1
  enblend: out of memory
  enblend: std::bad_alloc

  This is a simple 0.5Gpixel panorama I shot. And agreed, Hugin did warn
  me that it might take a lot of memory.

  The thing is: There is no other tool to stitch this with, so I'll have to 
make do with hugin and its toolset
  I thought there was an imagecache that would swap parts of images to disk...

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

___
Mailing list: https://launchpad.net/~hugin-devs
Post to : hugin-devs@lists.launchpad.net
Unsubscribe : https://launchpad.net/~hugin-devs
More help   : https://help.launchpad.net/ListHelp


[Hugin-devs] [Bug 685105] Re: enblend fails to blend large pano

2013-09-07 Thread kaefert
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 are a member of Hugin
Developers, which is subscribed to Enblend.
https://bugs.launchpad.net/bugs/685105

Title:
  enblend fails to blend large pano

Status in Enblend:
  Confirmed

Bug description:
  Enblend failed with:

  enblend --compression=LZW -m 1200 -w -f135659x3947+0+1091 -o pano8110_l.tif 

  ...
  enblend: info: loading next image: pano8110_l.tif 1/1
  enblend: out of memory
  enblend: std::bad_alloc

  This is a simple 0.5Gpixel panorama I shot. And agreed, Hugin did warn
  me that it might take a lot of memory.

  The thing is: There is no other tool to stitch this with, so I'll have to 
make do with hugin and its toolset
  I thought there was an imagecache that would swap parts of images to disk...

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

___
Mailing list: https://launchpad.net/~hugin-devs
Post to : hugin-devs@lists.launchpad.net
Unsubscribe : https://launchpad.net/~hugin-devs
More help   : https://help.launchpad.net/ListHelp


[Hugin-devs] [Bug 685105] Re: enblend fails to blend large pano

2013-09-06 Thread kaefert
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)
Before I used LinuxMint14 (~Ubuntu 12.10) with 10GB of RAM and 10GB of swap and 
enblend made it much farer, and only crashed with this error around picture nr. 
280 (there are 330 in total)

This is my output in the hugin logfile:

...
enblend: info: loading next image: name0226.tif 1/1
enblend: info: loading next image: name0227.tif 1/1

enblend: out of memory
enblend: std::bad_alloc
enblend: info: remove invalid output image name.tif
make: *** [name.tif] Error 1

So as I understand the workaround for this bug is to compile enblend
yourself and set some option imagecache to false or something? Could
someone guide me how to do this?

-- 
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 large pano

Status in Enblend:
  Confirmed

Bug description:
  Enblend failed with:

  enblend --compression=LZW -m 1200 -w -f135659x3947+0+1091 -o pano8110_l.tif 

  ...
  enblend: info: loading next image: pano8110_l.tif 1/1
  enblend: out of memory
  enblend: std::bad_alloc

  This is a simple 0.5Gpixel panorama I shot. And agreed, Hugin did warn
  me that it might take a lot of memory.

  The thing is: There is no other tool to stitch this with, so I'll have to 
make do with hugin and its toolset
  I thought there was an imagecache that would swap parts of images to disk...

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

___
Mailing list: https://launchpad.net/~hugin-devs
Post to : hugin-devs@lists.launchpad.net
Unsubscribe : https://launchpad.net/~hugin-devs
More help   : https://help.launchpad.net/ListHelp


[Hugin-devs] [Bug 685105] Re: enblend fails to blend large pano

2013-09-06 Thread kaefert
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, which is subscribed to Enblend.
https://bugs.launchpad.net/bugs/685105

Title:
  enblend fails to blend large pano

Status in Enblend:
  Confirmed

Bug description:
  Enblend failed with:

  enblend --compression=LZW -m 1200 -w -f135659x3947+0+1091 -o pano8110_l.tif 

  ...
  enblend: info: loading next image: pano8110_l.tif 1/1
  enblend: out of memory
  enblend: std::bad_alloc

  This is a simple 0.5Gpixel panorama I shot. And agreed, Hugin did warn
  me that it might take a lot of memory.

  The thing is: There is no other tool to stitch this with, so I'll have to 
make do with hugin and its toolset
  I thought there was an imagecache that would swap parts of images to disk...

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

___
Mailing list: https://launchpad.net/~hugin-devs
Post to : hugin-devs@lists.launchpad.net
Unsubscribe : https://launchpad.net/~hugin-devs
More help   : https://help.launchpad.net/ListHelp


[Hugin-devs] [Bug 685105] Re: enblend fails to blend large pano

2013-09-06 Thread kaefert
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 your way now, will report back when
there's news.

-- 
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 large pano

Status in Enblend:
  Confirmed

Bug description:
  Enblend failed with:

  enblend --compression=LZW -m 1200 -w -f135659x3947+0+1091 -o pano8110_l.tif 

  ...
  enblend: info: loading next image: pano8110_l.tif 1/1
  enblend: out of memory
  enblend: std::bad_alloc

  This is a simple 0.5Gpixel panorama I shot. And agreed, Hugin did warn
  me that it might take a lot of memory.

  The thing is: There is no other tool to stitch this with, so I'll have to 
make do with hugin and its toolset
  I thought there was an imagecache that would swap parts of images to disk...

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

___
Mailing list: https://launchpad.net/~hugin-devs
Post to : hugin-devs@lists.launchpad.net
Unsubscribe : https://launchpad.net/~hugin-devs
More help   : https://help.launchpad.net/ListHelp