date:20160903

[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 ner0

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

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

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

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

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

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

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

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

Status in Hugin:
  Won't Fix

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

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

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

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

  Is there some hint any of the devs can give me how to work around this 
problem?
  In two of my previous panoramas I've stiched the 4 relevant faces seperatly 
directly with a linear projection, though I dislike this aproach because it's 
nearly impossible to make the 4 seams manually match. See:
  
https://kaefert.is-a-geek.org/SaladoPlayer-1.3.5/?pano=blindengasse55_2014-01-10=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 1307023] Re: nona crashes with std::bad_alloc when input has more than 2^31 pixels

2016-09-03 Thread ner0

Hello.

Sorry to come into this old discussion.
I see that the status of this bug report is "Won't Fix" but the last user 
before me mentioned that it might be possible to build the VIGRA library using 
a 64bit compiler and overcome the limitation. I'd like to help out but don't 
know where to start. I'm not a coder but I'm facing the exact same problem 
where cubic2erect will fail when using nona with the error "std::bad_alloc".

I tried getting the 64bit compiled version of vigraimpex and using that
instead of libvigraimpex but needless to say that I don't know what I am
doing.

I almost had success using Hugin's 2015 64bit version but that gave me another 
different error:
ERROR:  
(c:\users\harryvanderwolf\downloads\hugin-sdk\sdk\hugin-2015.0.0\src\hugin_base\nona\Stitcher.h:547)
 HuginBase::Nona::WeightedStitcher,class std::allocator > >,class vigra::BasicImage > >::stitch(): exception during 
stitching
Precondition violation!
separableConvolveX(): kernel longer than line

(c:\users\harryvanderwolf\downloads\hugin-
sdk\sdk\vigra\include\vigra\separableconvolution.hxx:1103)

Nevertheless it produced the final image (527 MB - 25132x12566px) with 85% 
accuracy.
The missing 15% are because it is literally missing a full chunk (always the 
right side of the cubic panorama).


EDIT: Well, I was about to finish this off when I browsed through the 
sourceforge folders and saw the 2016.2 RC2 64bit version. And what do you know, 
it solves the issue completely! No more errors or missing chunks, it just works!

Thanks to the community and mainly the developers for all their hard
work.

Cheers!

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

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

Status in Hugin:
  Won't Fix

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

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

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

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

  Is there some hint any of the devs can give me how to work around this 
problem?
  In two of my previous panoramas I've stiched the 4 relevant faces seperatly 
directly with a linear projection, though I dislike this aproach because it's 
nearly impossible to make the 4 seams manually match. See:
  
https://kaefert.is-a-geek.org/SaladoPlayer-1.3.5/?pano=blindengasse55_2014-01-10=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 1617676] Re: hugin is crashing on start

2016-09-03 Thread tmodes

** Changed in: hugin
   Status: New => Won't Fix

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

Title:
  hugin is crashing on start

Status in Hugin:
  Won't Fix

Bug description:
  I keep getting an error and then a crash when i begin hugin. The error
  is:

  /usr/include/wx-3.0/wx/object.h(160): assert "wxDynamicCast(ptr, T)"
  failed in wxCheckCast(): wxStaticCast() used incorrectly

  I've repeated this numerous times and it keeps doing it.

  Here is some info:
  Operating System: Linux 3.19.0-32-generic x86_64 (Mint 17.3)
  Architecture: 64 bit 
  Free memory: 140052198648283 kiB 
   Hugin 
  Version: 2016.0.0.3b4e2790cb90 
  Path to resources: /usr/share/hugin/xrc/ 
  Path to data: /usr/share/hugin/data/ 
  Hugins camera and lens database: /home/bmike1/.hugindata/camlens.db 
  Multi-threading using C++11 std::thread and OpenMP 
  Monitor profile: Screen 1 #1 2016-06-29 13-30 S XYZLUT+MTX 

  The system is updated almost daily.

  here is the debug report on googledrive (and the last .pto file I
  successfully completed):

  https://drive.google.com/open?id=0B2xvsVTZy4y1NXBsN1VzV1B1R2s

  sometimes the debug report window does not open.

  I opened the batch processor and it happily ran.

To manage notifications about this bug go to:
https://bugs.launchpad.net/hugin/+bug/1617676/+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 1616039] Re: link not resolved

2016-09-03 Thread tmodes

This should be fixed in the upcoming 2016.2 version.
There is already a rc1, please test this.

** Changed in: hugin
   Status: New => Incomplete

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

Title:
  link not resolved

Status in Hugin:
  Incomplete

Bug description:
  Version: 2014.0.0 built by Matthieu DESILE

  The problem:
  in HuginTools points
  matchpoint -> ../Hugin.app/Contents/MacOS/matchpoint

  but 'matchpoint' is missing in Hugin.app

To manage notifications about this bug go to:
https://bugs.launchpad.net/hugin/+bug/1616039/+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 1602969] Re: 2016.rc1 win7 64bit crashes during import

2016-09-03 Thread tmodes

** Changed in: hugin
Milestone: 2016.4beta1 => 2016.2rc2

** Changed in: hugin
   Status: Fix Committed => Fix Released

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

Title:
  2016.rc1 win7 64bit crashes during import

Status in Hugin:
  Fix Released

Bug description:
  During import of 16bit tif images (60 images of roughly 15MP/100MB
  size each) it crashes.

  Only change in Settings: Imagecache 6000MB. If it is set to standard
  256MB it doesnt crash, so may be the 64bit msi installer isn´t 64bit?

  That would accord to  Freier Speicher: (free Ram) 4194303 kiB ...

  The imagecache setting should test if the settings are useful and
  correct.


  Machine is:
  Dell Precision 5810 Workstation @ 32G Ram 

  Betriebssystem: Windows 7 (build 7601, Service Pack 1), 64-bit edition
  Architektur: 64 bit
  Freier Speicher: 4194303 kiB
  Aktive Codepage: 1252 (Western European Windows)

  Hugin
  Version: 2016.0.0.3b4e2790cb90 built by Jan Dubiec 
  Ressourcen-Pfad: C:\Program Files (x86)\Hugin\share\hugin\xrc\
  Datenpfad: C:\Program Files (x86)\Hugin\share\hugin\data\
  Hugins Kamera- und Objektivdatenbank: 
C:\Users\urs.obernolte\AppData\Roaming\hugin\camlens.db
  Multi-Threading mittels C++11 std::thread und OpenMP
  Monitorprofile: C:\Windows\system32\spool\drivers\color\Samsung PnP- 
(Standard)-1.icm

  Bibliotheken
  wxWidgets: wxWidgets 3.1
  wxWidgets Library (wxMSW port)
  Version 3.1.0 (Unicode: wchar_t, debug level: 1),
  compiled at Mar 27 2016 18:20:50

  Runtime version of toolkit used is 6.1.

  libpano13: 2.9.19 
  Boost: 1.60.0
  Exiv2: 0.25
  SQLite3: 3.10.2
  Vigra: 1.11.0
  LittleCMS2: 2.7

To manage notifications about this bug go to:
https://bugs.launchpad.net/hugin/+bug/1602969/+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 1605762] Re: Spanish translation

2016-09-03 Thread tmodes

** Changed in: hugin
Milestone: 2016.4beta1 => 2016.2rc2

** Changed in: hugin
   Status: Fix Committed => Fix Released

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

Title:
  Spanish translation

Status in Hugin:
  Fix Released

Bug description:
  Just tested .mo file, if someone can re-compile hugin please report
  back any missing translation.

To manage notifications about this bug go to:
https://bugs.launchpad.net/hugin/+bug/1605762/+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

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

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

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

[Hugin-devs] [Bug 1617676] Re: hugin is crashing on start

[Hugin-devs] [Bug 1616039] Re: link not resolved

[Hugin-devs] [Bug 1602969] Re: 2016.rc1 win7 64bit crashes during import

[Hugin-devs] [Bug 1605762] Re: Spanish translation

8 matches

Site Navigation

Mail list logo

Footer information