[Hugin-devs] [Bug 1306915] Re: Batch image adjuster cannot work with non-ascii path names

2014-04-12 Thread tmodes
*** This bug is a duplicate of bug 678808 ***
https://bugs.launchpad.net/bugs/678808

** This bug has been marked a duplicate of bug 678808
   could not decode image when path contains non-latin chars

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

Title:
  Batch image adjuster cannot work with non-ascii path names

Status in Hugin - Panorama Tools GUI:
  New

Bug description:
  If you load your images from a folder named using localized letters,
  the batch adjuster won't work, bailing out with an error and a message
  to deploy control points manually. Moving images to folder with ascii
  name works-around the problem.

  Hugin v.2013.0.0.0d404a7088e6 built by Matthew Petroff

To manage notifications about this bug go to:
https://bugs.launchpad.net/hugin/+bug/1306915/+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-12 Thread Christoph Spiel
WRT your original errors.  They point to outdated OpenCL header files.
Ask your sysadmin to get the most recent versions from
http://www.khronos.org/opencl/
and install them in the appropriate place.

Next thing on her agenda is to update the OpenCL libraries to their
latest versions.  Again, the older versions tend to be much buggier
than recent ones.

The complete OpenCL environment (headers, drivers, libraries, etc.)
must work perfectly before you can expect Enblend to even try to
utilize the GPU.

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