[Hugin-devs] [Bug 2053287] Re: sometimes there are black patches/corners in blended images

2024-02-18 Thread Bruno Postle
I'm not using msvc. This error is with fedora, but it looks like vigra
in Ubuntu has already been patched to support c++17. The fedora vigra
maintainer needs to copy some Ubuntu patches.

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

Title:
  sometimes there are black patches/corners in blended images

Status in Enblend:
  Fix Committed

Bug description:
  As has been known for a long time, enblend sometimes produces black
  patches in the corners of subimages.

  As we have discussed by email, I'd like to suggest a patch for that:
   -- patch1 contains the pyramid type to make the following simpler
   -- patch2 contains the actual change where the mask is corrected using both 
alpha layers prior to the actual blending step
   -- patch3 are two small functional changes that are unrelated to the main 
issue
   -- patch4 are modernisation and style improvements, that I just had to do 
while working on the code.  If you think some of them don't add enough (or any) 
value, feel free to drop some.

  cheers, lukas wirz

To manage notifications about this bug go to:
https://bugs.launchpad.net/enblend/+bug/2053287/+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 2053287] Re: sometimes there are black patches/corners in blended images

2024-02-18 Thread Bruno Postle
Can confirm that the patched enblend passes all the tests that I
uploaded here:

https://bugs.launchpad.net/enblend/+bug/721136/comments/18

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

Title:
  sometimes there are black patches/corners in blended images

Status in Enblend:
  Fix Committed

Bug description:
  As has been known for a long time, enblend sometimes produces black
  patches in the corners of subimages.

  As we have discussed by email, I'd like to suggest a patch for that:
   -- patch1 contains the pyramid type to make the following simpler
   -- patch2 contains the actual change where the mask is corrected using both 
alpha layers prior to the actual blending step
   -- patch3 are two small functional changes that are unrelated to the main 
issue
   -- patch4 are modernisation and style improvements, that I just had to do 
while working on the code.  If you think some of them don't add enough (or any) 
value, feel free to drop some.

  cheers, lukas wirz

To manage notifications about this bug go to:
https://bugs.launchpad.net/enblend/+bug/2053287/+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 2053287] Re: sometimes there are black patches/corners in blended images

2024-02-18 Thread Bruno Postle
It also passes the test case I uploaded here:

https://bugs.launchpad.net/enblend/+bug/785803/comments/8

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

Title:
  sometimes there are black patches/corners in blended images

Status in Enblend:
  Fix Committed

Bug description:
  As has been known for a long time, enblend sometimes produces black
  patches in the corners of subimages.

  As we have discussed by email, I'd like to suggest a patch for that:
   -- patch1 contains the pyramid type to make the following simpler
   -- patch2 contains the actual change where the mask is corrected using both 
alpha layers prior to the actual blending step
   -- patch3 are two small functional changes that are unrelated to the main 
issue
   -- patch4 are modernisation and style improvements, that I just had to do 
while working on the code.  If you think some of them don't add enough (or any) 
value, feel free to drop some.

  cheers, lukas wirz

To manage notifications about this bug go to:
https://bugs.launchpad.net/enblend/+bug/2053287/+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 2053287] Re: sometimes there are black patches/corners in blended images

2024-02-18 Thread Bruno Postle
Yes, I replaced the `throw(PreconditionViolation)` with
`noexcept(false)` in both vigra locations and now enblend builds.


I'm using enblend cmake, as the autoconf stuff needed bootstrapping and I 
couldn't remember how to do it.


Haven't tested the bugfix yet, I seem to remember I created test cases with 
several examples that all failed at some time.

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

Title:
  sometimes there are black patches/corners in blended images

Status in Enblend:
  Fix Committed

Bug description:
  As has been known for a long time, enblend sometimes produces black
  patches in the corners of subimages.

  As we have discussed by email, I'd like to suggest a patch for that:
   -- patch1 contains the pyramid type to make the following simpler
   -- patch2 contains the actual change where the mask is corrected using both 
alpha layers prior to the actual blending step
   -- patch3 are two small functional changes that are unrelated to the main 
issue
   -- patch4 are modernisation and style improvements, that I just had to do 
while working on the code.  If you think some of them don't add enough (or any) 
value, feel free to drop some.

  cheers, lukas wirz

To manage notifications about this bug go to:
https://bugs.launchpad.net/enblend/+bug/2053287/+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 2053287] Re: sometimes there are black patches/corners in blended images

2024-02-18 Thread Bruno Postle
I can't get the latest mercurial with patches to build, this doesn't
really make sense to me as enblend requires c++17:


```
/usr/include/vigra/separableconvolution.hxx:1413:13: error: ISO C++17 does not 
allow dynamic exception specifications
 1413 | throw(PreconditionViolation)
  | ^
/usr/include/vigra/stdconvolution.hxx:796:13: error: ISO C++17 does not allow 
dynamic exception specifications
  796 | throw(PreconditionViolation)
  | ^
```

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

Title:
  sometimes there are black patches/corners in blended images

Status in Enblend:
  New

Bug description:
  As has been known for a long time, enblend sometimes produces black
  patches in the corners of subimages.

  As we have discussed by email, I'd like to suggest a patch for that:
   -- patch1 contains the pyramid type to make the following simpler
   -- patch2 contains the actual change where the mask is corrected using both 
alpha layers prior to the actual blending step
   -- patch3 are two small functional changes that are unrelated to the main 
issue
   -- patch4 are modernisation and style improvements, that I just had to do 
while working on the code.  If you think some of them don't add enough (or any) 
value, feel free to drop some.

  cheers, lukas wirz

To manage notifications about this bug go to:
https://bugs.launchpad.net/enblend/+bug/2053287/+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 2045960] Re: hugin 2023.0.0: three asserts with wxgtk 3.2.4

2023-12-08 Thread Bruno Postle
I don't see this with Hugin 2023.0.0 and wxgtk 3.2.4 (fedora 39 default
packages)

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

Title:
  hugin 2023.0.0: three asserts with wxgtk 3.2.4

Status in Hugin:
  Incomplete

Bug description:
  On startup when compiled against wxgtk 3.2.4 I get 3 asserts (that I
  don't get when compiled against wxgtk 3.1.7) I can click continue and
  hugin appears to work despite the errors on startup:

  
  ASSERT INFO:
  
/var/tmp/paludis/build/x11-libs-wxGTK-3.2.4/work/wxWidgets-3.2.4/src/gtk/dc.cpp(497):
 assert ""cr"" failed in wxPaintDCImpl(): using wxPaintDC without being in a 
native paint event

  BACKTRACE:
  [1] wxPaintDC::wxPaintDC(wxWindow*)
  [2] wxEvtHandler::ProcessEventIfMatchesId(wxEventTableEntryBase const&, 
wxEvtHandler*, wxEvent&)
  [3] wxEventHashTable::HandleEvent(wxEvent&, wxEvtHandler*)
  [4] wxEvtHandler::TryHereOnly(wxEvent&)
  [5] wxEvtHandler::ProcessEventLocally(wxEvent&)
  [6] wxEvtHandler::ProcessEvent(wxEvent&)
  [7] wxEvtHandler::SafelyProcessEvent(wxEvent&)
  [8] wxWindow::GTKSendPaintEvents(_cairo*)
  [9] g_closure_invoke
  [10] g_signal_emit_valist
  [11] g_signal_emit
  [12] gtk_container_propagate_draw
  [13] g_closure_invoke
  [14] g_signal_emit_valist
  [15] g_signal_emit
  [16] gtk_container_propagate_draw
  [17] g_closure_invoke
  [18] g_signal_emit_valist
  [19] g_signal_emit
  [20] gtk_container_propagate_draw
  [21] g_closure_invoke
  [22] g_signal_emit_valist
  [23] g_signal_emit
  [24] gtk_container_propagate_draw
  [25] gtk_container_propagate_draw
  [26] gtk_main_do_event
  [27] wxWindow::Update()
  [28] wxAuiManager::OnSize(wxSizeEvent&)
  [29] wxEvtHandler::ProcessEventIfMatchesId(wxEventTableEntryBase const&, 
wxEvtHandler*, wxEvent&)
  [30] wxEventHashTable::HandleEvent(wxEvent&, wxEvtHandler*)
  [31] wxEvtHandler::TryHereOnly(wxEvent&)
  [32] wxEvtHandler::ProcessEventLocally(wxEvent&)
  [33] wxEvtHandler::ProcessEvent(wxEvent&)
  [34] wxEvtHandler::SafelyProcessEvent(wxEvent&)
  [35] wxWindow::DoSetSize(int, int, int, int, int)
  [36] wxBoxSizer::RepositionChildren(wxSize const&)
  [37] wxSizer::Layout()
  [38] wxWindowBase::Layout()
  [39] wxEvtHandler::ProcessEventIfMatchesId(wxEventTableEntryBase const&, 
wxEvtHandler*, wxEvent&)
  [40] wxEventHashTable::HandleEvent(wxEvent&, wxEvtHandler*)
  [41] wxEvtHandler::TryHereOnly(wxEvent&)
  [42] wxEvtHandler::ProcessEventLocally(wxEvent&)
  [43] wxEvtHandler::ProcessEvent(wxEvent&)
  [44] wxEvtHandler::SafelyProcessEvent(wxEvent&)
  [45] g_closure_invoke
  [46] g_signal_emit_valist
  [47] g_signal_emit
  [48] gtk_widget_size_allocate_with_baseline
  [49] gtk_widget_size_allocate_with_baseline
  [50] g_closure_invoke
  [51] g_signal_emit_valist
  [52] g_signal_emit
  [53] gtk_widget_size_allocate_with_baseline
  [54] g_signal_emit_valist
  [55] g_signal_emit
  [56] g_closure_invoke
  [57] g_signal_emit_valist
  [58] g_signal_emit
  [59] g_main_context_iteration
  [60] gtk_main_iteration
  [61] wxGUIEventLoop::DoYieldFor(long)
  [62] wxEventLoopBase::YieldFor(long)
  [63] wxAppConsoleBase::Yield(bool)
  [64] wxEntry(int&, wchar_t**)
  [65] __libc_start_main

  
  ASSERT INFO:
  
/var/tmp/paludis/build/x11-libs-wxGTK-3.2.4/work/wxWidgets-3.2.4/src/common/dcgraph.cpp(466):
 assert ""IsOk()"" failed in SetTextForeground(): wxGCDC(cg)::SetTextForeground 
- invalid DC

  BACKTRACE:
  [1] wxGCDCImpl::SetTextForeground(wxColour const&)
  [2] wxDCImpl::InheritAttributes(wxWindow*)
  [3] wxPaintDC::wxPaintDC(wxWindow*)
  [4] wxEvtHandler::ProcessEventIfMatchesId(wxEventTableEntryBase const&, 
wxEvtHandler*, wxEvent&)
  [5] wxEventHashTable::HandleEvent(wxEvent&, wxEvtHandler*)
  [6] wxEvtHandler::TryHereOnly(wxEvent&)
  [7] wxEvtHandler::ProcessEventLocally(wxEvent&)
  [8] wxEvtHandler::ProcessEvent(wxEvent&)
  [9] wxEvtHandler::SafelyProcessEvent(wxEvent&)
  [10] wxWindow::GTKSendPaintEvents(_cairo*)
  [11] g_closure_invoke
  [12] g_signal_emit_valist
  [13] g_signal_emit
  [14] gtk_container_propagate_draw
  [15] g_closure_invoke
  [16] g_signal_emit_valist
  [17] g_signal_emit
  [18] gtk_container_propagate_draw
  [19] g_closure_invoke
  [20] g_signal_emit_valist
  [21] g_signal_emit
  [22] gtk_container_propagate_draw
  [23] g_closure_invoke
  [24] g_signal_emit_valist
  [25] g_signal_emit
  [26] gtk_container_propagate_draw
  [27] gtk_container_propagate_draw
  [28] gtk_main_do_event
  [29] wxWindow::Update()
  [30] wxAuiManager::OnSize(wxSizeEvent&)
  [31] wxEvtHandler::ProcessEventIfMatchesId(wxEventTableEntryBase const&, 
wxEvtHandler*, wxEvent&)
  [32] wxEventHashTable::HandleEvent(wxEvent&, wxEvtHandler*)
  [33] wxEvtHandler::TryHereOnly(wxEvent&)
  [34] wxEvtHandler::ProcessEventLocally(wxEvent&)
  [35] wxEvtHandler::ProcessEvent(wxEvent&)
  [36] wxEvtHandler::SafelyProcessEvent(wxEvent&)
  [37] wxWindow::DoSetSize(int, int, int, int, int)
  [38] 

[Hugin-devs] [Bug 2041687] Re: does not show/log enblend error messages

2023-10-28 Thread Bruno Postle
A fresh build seems ok here, the dummy script output is logged correctly
(stitching with enblend completes and logs as expected):

Blending images...
status on stdout
error in stderr

This is with wxwidgets 3.2.1

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

Title:
  does not show/log enblend error messages

Status in Hugin:
  Fix Committed

Bug description:
  Hello,

  hugin does not show/log enblend errors. I think it did previously.
  This is on 2023.0~beta1+dfsg-1.

  This was originally reported by Michael Deegan in
  https://bugs.debian.org/1054129

  It is easy to reproduce by replacing enblend with a dummy-script like this one
  -#!/bin/sh
  echo status on stdout
  echo error in stderr 1>&2
  exit 1
  --

  The corresponding logfile ends with 
  Remapping LDR images...
  Blending images...

  Process took 9 s

  cu Andreas

To manage notifications about this bug go to:
https://bugs.launchpad.net/hugin/+bug/2041687/+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 847433] Re: 'Create panorama' is disabled in single photo projects

2023-09-10 Thread Bruno Postle
I think that loading an equirectangular and extracting a single manually
chosen narrow angle view image is something lots of people would want to
do. This came up because somebody asked me how to create cube faces, in
this case it should be possible to do this with just a 'load' and
'create' click.

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

Title:
  'Create panorama' is disabled in single photo projects

Status in Hugin:
  New

Bug description:
  When starting a project, both 2. Align... and 3. Create panorama are
  greyed out which makes sense.

  However if I load a single photo into Hugin, they are still greyed.
  This is a problem as a common use of Hugin for me is to load a single
  image and remap it to a different projection.

To manage notifications about this bug go to:
https://bugs.launchpad.net/hugin/+bug/847433/+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 847433] Re: 'Create panorama' is disabled in single photo projects

2023-09-08 Thread Bruno Postle
** Changed in: hugin
   Status: Fix Released => New

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

Title:
  'Create panorama' is disabled in single photo projects

Status in Hugin:
  New

Bug description:
  When starting a project, both 2. Align... and 3. Create panorama are
  greyed out which makes sense.

  However if I load a single photo into Hugin, they are still greyed.
  This is a problem as a common use of Hugin for me is to load a single
  image and remap it to a different projection.

To manage notifications about this bug go to:
https://bugs.launchpad.net/hugin/+bug/847433/+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 847433] Re: 'Create panorama' is disabled in single photo projects

2023-09-08 Thread Bruno Postle
Reopening this as there is a regression!

I tried to use the 'equi and cubic' output to convert a single
equirectangular image to cubic, but 'Create Panorama' isn't enabled
unless the 'Align' step has completed so this isn't available.

Workaround is to create a dummy vertical control-point with zero error,
then Align, and Create Panorama > Equi and cubic.

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

Title:
  'Create panorama' is disabled in single photo projects

Status in Hugin:
  Fix Released

Bug description:
  When starting a project, both 2. Align... and 3. Create panorama are
  greyed out which makes sense.

  However if I load a single photo into Hugin, they are still greyed.
  This is a problem as a common use of Hugin for me is to load a single
  image and remap it to a different projection.

To manage notifications about this bug go to:
https://bugs.launchpad.net/hugin/+bug/847433/+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 2007177] Re: Hugin freezes after opening Fast Panorama Preview for a second time

2023-02-13 Thread Bruno Postle
I can't reproduce on fedora 37:

hugin 2022.0.0
glew 2.2.0
wxGTK-3.2.1 (but wx is built without egl support on fedora)
gtk3 3.24.36
Wayland

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

Title:
  Hugin freezes after opening Fast Panorama Preview for a second time

Status in Hugin:
  New

Bug description:
  1. Open Hugin in expert mode
  2. Load a project
  3. Open Fast Panorama Preview
  4. Close Fast Panorama Preview with the window close button (cross)
  5. Open Fast Panorama Preview
  6. Hugin freezes and GNOME says "Hugin Panorama Creator" is not responding
 and offers to force quit

  Hugin 2022.0.0
  GLEW 2.2.0 compiled with SYSTEM=linux-egl
  wxGTK 3.2.1 with Wayland support
  GTK 3.24.36
  GNOME 43, Wayland
  Gentoo Linux

To manage notifications about this bug go to:
https://bugs.launchpad.net/hugin/+bug/2007177/+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 2007178] Re: Replace GLEW with epoxy

2023-02-13 Thread Bruno Postle
I haven't tested the patch, just noting that epoxy is available on
fedora

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

Title:
  Replace GLEW with epoxy

Status in Hugin:
  New

Bug description:
  GLEW is installed for either GLX or EGL, making it impossible to switch to 
EGL if some applications need GLX.
  epoxy also does not need to be initialised, making startup faster.
  GTK, Firefox and Libreoffice are among those using epoxy.

  Patch (not sure the best way to work with Launchpad and/or Sourceforge...):
  https://sourceforge.net/p/hugin/hugin/merge-requests/2/

  A draft that has only been tested on Linux and at the moment uses
  PKG_SEARCH_MODULE to find epoxy. So, may work on macOS (libepoxy is
  available in Homebrew) but more work for Windows and other supporting
  scripts.

To manage notifications about this bug go to:
https://bugs.launchpad.net/hugin/+bug/2007178/+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 1974200] Re: Website is not updated

2022-05-22 Thread Bruno Postle
This should now be fixed, the machine I was using to update the website
remotely died in October.

In the process I seem to have switched the website to https, which seems
to be ok, i.e. links like this: http://hugin.sourceforge.net/download/
are now automatically redirected to
https://hugin.sourceforge.io/download/

** Changed in: hugin
   Status: New => 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/1974200

Title:
  Website is not updated

Status in Hugin:
  Fix Released

Bug description:
  Website  http://hugin.sourceforge.net/ lists as last release Hugin
  2020.0.0

  If i go directly to
  http://hugin.sourceforge.net/releases/2021.0.0/en.shtml i can view
  2021 release notes as expected.

  However changes in index.shtml  and news.html  and
  releases/index.shtml and  download/index.shtml

  (made in commit  
https://sourceforge.net/p/hugin/hugin-web/ci/d7953db65cdf2d645e832c62c2c5ebf264f4/
 )
  disnt show on website.

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


Re: [Hugin-devs] [Bug 1956190] [NEW] align_image_stack is doing a poor job

2022-01-03 Thread Bruno Postle
I haven't tested with the photos, but this does seem like it ought to
work.

The Yahoo mailing list is gone, but the hugin-ptx list is active and is a
good place to ask about align_image_stack usage:
https://groups.google.com/g/hugin-ptx/

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

Title:
  align_image_stack is doing a poor job

Status in Hugin:
  New

Bug description:
  A scenario is described in https://photo.stackexchange.com/q/128167/82107
  align_image_stack is doing a poor job trying to align a series of "free-hand" 
shots.
  It's not obvious what's wrong.
  (The panotools mailinglist at yahoo seems dead)

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


Re: [Hugin-devs] [Bug 1955993] [NEW] Dijkstra optimizer and defective seam line => no final panorama

2021-12-30 Thread Bruno Postle
For a sky panorama, you likely don't need enblend seam optimisation, it
looks to be counterproductive in this case, try stitching again but add the
enblend --no-optimize parameter.

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

Title:
  Dijkstra optimizer and defective seam line => no final panorama

Status in Hugin:
  New

Bug description:
  Hi, 
  I am stressed out.
  40 hours of work and nor result.

  Goal: Panorama 360x180° 18mm APS-C nighttime with stars.

  Way to: - Conekting the frames by pionts (inkluding stars)
  - Autoadd more points
  - reduced to low distance between points
  - and finalisation, no way!

  Here is the error-log (german):
   

  
  Panorama zusammenfügen...
  

  Plattform: Windows 10 (build 19043), 64-bit edition
  Version: 2020.0.0.2f576e5d5b4a built by Thomas
  Aktuelles Verzeichnis: I:\AstroFoto 1\Prosessing\Zwischen 
Ordner\Moon-Pano360\PrePano360Test
  Ausgabe-Präfix: Bitte3

  Überblendung: enblend 4.3-6b604e79e85b
  Belichtungsfusion: enfuse 4.3-6b604e79e85b
  ExifTool-Version: 12.08

  Anzahl der aktiven Bilder: 219
  Ausgabe-Belichtungswert: -4,0
  Rahmengrösse: 27108x13554
  ROI: (0, 0) - (27108, 13554) 
  FOV: 360x180
  Projektion: Sphärisch (Equirectangular)(2)
  Verwende GPU für Umberechnung: wahr

  Panorama-Ausgabe:
  * Mit Belichtungskorrektur, niedriger Dynamikumfang
  * Belichtungsfusion aus Stapeln
  * Belichtungsfusion von beliebiger Anordnung

  Erstes Quell-Bild
  Nummer: 0
  Dateiname: I:\AstroFoto 1\Prosessing\Zwischen 
Ordner\Moon-Pano360\PrePano360Test\IMG_6950.jpg
  Größe: 3670x5496
  Projektion: Gradlinig (Rectilinear)
  Kamerakurve: Benutzerdefiniert (EMoR)
  HFOV: 46
  Belichtungswert: -4,2

  
  Umberechnung von LDR-Bildern…
  nona: using graphics card: NVIDIA Corporation NVIDIA GeForce GTX 1060 
3GB/PCIe/SSE2
  Multiple images output
  loading IMG_6950.jpg
  remapping IMG_6950.jpg
  saving Bitte3.tif
  loading IMG_6951.jpg
  remapping IMG_6951.jpg
  ..
  up to
  ..
  loading IMG_7241.jpg
  remapping IMG_7241.jpg
  saving Bitte30218.tif

  
  Überblendung der Bilder…
  enblend: warning: unable to run Dijkstra optimizer
  enblend: note: seam-line end point outside of cost-image
  enblend: note: contour #1 of 1, segment #1 of 1, vertex #2680 of 2858
  enblend: warning: unable to run Dijkstra optimizer
  enblend: note: seam-line end point outside of cost-image
  enblend: note: contour #1 of 1, segment #1 of 1, vertex #2767 of 2946
  enblend: warning: unable to run Dijkstra optimizer
  enblend: note: seam-line end point outside of cost-image
  enblend: note: contour #2 of 2, segment #1 of 2, vertex #426 of 427
  enblend: warning: unable to run Dijkstra optimizer
  enblend: note: seam-line end point outside of cost-image
  enblend: note: contour #1 of 9, segment #2 of 11, vertex #33 of 34
  enblend: warning: unable to run Dijkstra optimizer
  enblend: note: seam-line end point outside of cost-image
  enblend: note: contour #1 of 9, segment #7 of 11, vertex #43 of 44
  enblend: warning: unable to run Dijkstra optimizer
  enblend: note: seam-line end point outside of cost-image
  enblend: note: contour #1 of 9, segment #8 of 11, vertex #29 of 30
  enblend: warning: unable to run Dijkstra optimizer
  enblend: note: seam-line end point outside of cost-image
  enblend: note: contour #1 of 13, segment #1 of 4, vertex #33 of 34
  enblend: warning: unable to run Dijkstra optimizer
  enblend: note: seam-line end point outside of cost-image
  enblend: note: contour #4 of 13, segment #3 of 9, vertex #42 of 43
  enblend: warning: unable to run Dijkstra optimizer
  enblend: note: seam-line end point outside of cost-image
  enblend: note: contour #4 of 13, segment #4 of 9, vertex #22 of 23
  enblend: warning: unable to run Dijkstra optimizer
  enblend: note: seam-line end point outside of cost-image
  enblend: note: contour #4 of 13, segment #5 of 9, vertex #22 of 23
  enblend: warning: unable to run Dijkstra optimizer
  enblend: note: seam-line end point outside of cost-image
  enblend: note: contour #5 of 13, segment #1 of 2, vertex #42 of 43
  enblend: warning: unable to run Dijkstra optimizer
  enblend: note: seam-line end point outside of cost-image
  enblend: note: contour #9 of 13, segment #2 of 5, vertex #46 of 47
  enblend: warning: unable to run Dijkstra optimizer
  enblend: note: seam-line end point outside of cost-image
  enblend: note: contour #9 of 13, segment #3 of 5, vertex #53 of 54
  enblend: warning: unable to run Dijkstra optimizer
  enblend: note: seam-line end point outside of cost-image
  enblend: note: contour #9 of 13, segment #4 of 5, vertex #41 of 42
  enblend: warning: unable to run Dijkstra optimizer
  enblend: note: seam-line end point outside of cost-image
  enblend: note: contour #12 of 13, segment #2 of 5, vertex #11 of 46
  

Re: [Hugin-devs] [Bug 1939930] Re: Include mask and MOST of 2nd image black

2021-08-15 Thread Bruno Postle
Yes, does this fix the problem for you?

-- 
Bruno

On 15 August 2021 04:34:05 CEST, Scott Cowles Jacobs wrote:
>The only options on the Blender dropdown are Enfuse and builtin.
>
>I guess that "builtin" is verdandi...?

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

Title:
  Include mask and MOST of 2nd image black

Status in Hugin:
  New

Bug description:
  I have a 2-image pano that has a car in the overlapping section of the
  left image, and none in the overlapping section of the right one.

  I want the car to be there.

  Despite the car being there in the preview, it is missing in the final pano.
  Thinking that Hugin is automatically preferring the right over the left, I 
"cleverly" flipped both
  images so that the car was in the right image, and ran Hugin again.  Car 
still missing...

  I researched the problem, and came upon the concept of Masks, and how
  to make an include mask.

  I drew a polygon around the car, selected "Include Region", and then 
"Stitch!" (or possibly
  "3. Create panorama").

  The area of the mask is completely black on the left part of the final image.
  The right part of the image is also completely black, except for a thin 
horizontal strip along
  the top, which blends into the black.

  In searching for others who might have reported this bug, I came upon:
  https://answers.launchpad.net/hugin/+question/675074
  which suggests: "- add switch --primary-seam-generator=nft to the enblend 
options on the stitcher tab"
  Indeed, this solves the problem.

  However, the bug has not been fixed, even though it must have existed
  before "2018-10-11", as the very first comment contained the above
  suggestion.

  The same comment said: "Either the remapping stage has a bug or the blending 
program has problems in finding the correct seams for complex masks."
  There are only two images, and one mask, in my image - not "complex", then...

  Is there no way for Hugin/enblend to recognize the problem, and apply
  the solution automatically?

  Perhaps if an include mask is present, that should be enough to
  trigger it...

  ---

  scott@ASUS-Prime-B350MA:~$ uname -a
  Linux ASUS-Prime-B350MA 5.10.0-5-amd64 #1 SMP Debian 5.10.26-1 (2021-03-27) 
x86_64 GNU/Linux

  
  Using Sway 1.5, wlroots (libwlroots6:  Installed: 0.11.0-3) under Debian 
Testing

  Invoking About... yields an error message:
  "08:21:30 PM: can't open file '/usr/share/hugin/xrc/data/COPYING.txt' (error 
2: No such file or directory)   


 
  08:21:30 PM: File couldn't be loaded."

  However the System tab yields:

  "Operating System: Linux 5.10.0-5-amd64 x86_64
  Architecture: 64 bit
  Free memory: 10769072 kiB

  Hugin
  Version: 2020.0.0.2f576e5d5b4a
  Path to resources: /usr/share/hugin/xrc/
  Path to data: /usr/share/hugin/data/
  Hugins camera and lens database: /home/scott/.hugindata/camlens.db
  Multi-threading using C++11 std::thread and OpenMP

  Libraries
  wxWidgets: wxWidgets 3.0.5
  wxWidgets Library (wxGTK port)
  Version 3.0.5 (Unicode: wchar_t, debug level: 1),
  Runtime version of toolkit used is 3.24.
  Compile-time GTK+ version is 3.24.20.

  libpano13: 2.9.20 
  Boost: 1.74.0
  Exiv2: 0.27.3
  SQLite3: 3.34.1
  Vigra: 1.11.1
  LittleCMS2: 2.9"

  They don't list enblend/enfuse, but their version is: 4.2-8
  ---

  I will attach the .pto file, and the final image.

  If you want the original .jpg s  let me know.

  [I have checked the "copy logfile to clipboard" preference, but I get nothing
  upon "pasting" into my text editor - maybe because of Wayland (but I normally
  have no problem with ctrl-c/ctrl-v cutting and pasting) ... ]

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


Re: [Hugin-devs] [Bug 1939930] Re: Include mask and MOST of 2nd image black

2021-08-14 Thread Bruno Postle
The black areas are a long standing and intractable enblend bug. An
alternative is to use the 'verdandi internal Hugin blender', which is a
hugin option. This stitcher has a different feature-set, but may suit
you better.

On 14 August 2021 02:53:25 CEST, Scott Cowles Jacobs 
<1939...@bugs.launchpad.net> wrote:
>** Attachment added: "20210813_Hugin_Editor_Masks_Tab.png"
>   
> https://bugs.launchpad.net/hugin/+bug/1939930/+attachment/5517820/+files/20210813_Hugin_Editor_Masks_Tab.png
>

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

Title:
  Include mask and MOST of 2nd image black

Status in Hugin:
  New

Bug description:
  I have a 2-image pano that has a car in the overlapping section of the
  left image, and none in the overlapping section of the right one.

  I want the car to be there.

  Despite the car being there in the preview, it is missing in the final pano.
  Thinking that Hugin is automatically preferring the right over the left, I 
"cleverly" flipped both
  images so that the car was in the right image, and ran Hugin again.  Car 
still missing...

  I researched the problem, and came upon the concept of Masks, and how
  to make an include mask.

  I drew a polygon around the car, selected "Include Region", and then 
"Stitch!" (or possibly
  "3. Create panorama").

  The area of the mask is completely black on the left part of the final image.
  The right part of the image is also completely black, except for a thin 
horizontal strip along
  the top, which blends into the black.

  In searching for others who might have reported this bug, I came upon:
  https://answers.launchpad.net/hugin/+question/675074
  which suggests: "- add switch --primary-seam-generator=nft to the enblend 
options on the stitcher tab"
  Indeed, this solves the problem.

  However, the bug has not been fixed, even though it must have existed
  before "2018-10-11", as the very first comment contained the above
  suggestion.

  The same comment said: "Either the remapping stage has a bug or the blending 
program has problems in finding the correct seams for complex masks."
  There are only two images, and one mask, in my image - not "complex", then...

  Is there no way for Hugin/enblend to recognize the problem, and apply
  the solution automatically?

  Perhaps if an include mask is present, that should be enough to
  trigger it...

  ---

  scott@ASUS-Prime-B350MA:~$ uname -a
  Linux ASUS-Prime-B350MA 5.10.0-5-amd64 #1 SMP Debian 5.10.26-1 (2021-03-27) 
x86_64 GNU/Linux

  
  Using Sway 1.5, wlroots (libwlroots6:  Installed: 0.11.0-3) under Debian 
Testing

  Invoking About... yields an error message:
  "08:21:30 PM: can't open file '/usr/share/hugin/xrc/data/COPYING.txt' (error 
2: No such file or directory)   


 
  08:21:30 PM: File couldn't be loaded."

  However the System tab yields:

  "Operating System: Linux 5.10.0-5-amd64 x86_64
  Architecture: 64 bit
  Free memory: 10769072 kiB

  Hugin
  Version: 2020.0.0.2f576e5d5b4a
  Path to resources: /usr/share/hugin/xrc/
  Path to data: /usr/share/hugin/data/
  Hugins camera and lens database: /home/scott/.hugindata/camlens.db
  Multi-threading using C++11 std::thread and OpenMP

  Libraries
  wxWidgets: wxWidgets 3.0.5
  wxWidgets Library (wxGTK port)
  Version 3.0.5 (Unicode: wchar_t, debug level: 1),
  Runtime version of toolkit used is 3.24.
  Compile-time GTK+ version is 3.24.20.

  libpano13: 2.9.20 
  Boost: 1.74.0
  Exiv2: 0.27.3
  SQLite3: 3.34.1
  Vigra: 1.11.1
  LittleCMS2: 2.9"

  They don't list enblend/enfuse, but their version is: 4.2-8
  ---

  I will attach the .pto file, and the final image.

  If you want the original .jpg s  let me know.

  [I have checked the "copy logfile to clipboard" preference, but I get nothing
  upon "pasting" into my text editor - maybe because of Wayland (but I normally
  have no problem with ctrl-c/ctrl-v cutting and pasting) ... ]

To manage notifications about this bug go to:
https://bugs.launchpad.net/hugin/+bug/1939930/+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 1922039] Re: Segmentation fault from Resaveimage() in verdandi

2021-04-08 Thread Bruno Postle
Noting that this has been reported as a vigra bug:
https://github.com/ukoethe/vigra/issues/494

** Bug watch added: github.com/ukoethe/vigra/issues #494
   https://github.com/ukoethe/vigra/issues/494

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

Title:
  Segmentation fault from Resaveimage() in verdandi

Status in Hugin:
  New

Bug description:
  Hello,

  Using hugin (2020.0.0) software verdandi adopting vigra, I encountered on the 
segmentation fault error.
  The root cause is assumed to be from
  Illegal reference by void vigra::StandardValueAccessor::set(unsigned short, unsigned short*&).
  of debian package

  libvigraimpex-dev/focal,now 1.11.1+dfsg-7ubuntu1

  The set() is assumed to be out-of-bound without any appropriate check of the 
valid address dereferenced by scanline.
  (src: /include/vigra/impex.hxx:82-89)

  Vigra functions to the root cause are called starting from ResaveImage() in 
verdandi.cpp:213.
  I attach a proof-of-concept file for the sake of developers' testing.

  Below is the running command and backtrace;

  oren@ubuntu:~$ sudo ./hugin-2020.0.0/build/src/tools/verdandi --output=1.tif 
./poc
  Warning: no TIFFTAG_SAMPLEFORMAT or TIFFTAG_DATATYPE, guessing pixeltype 
'UINT16'.
  Warning: no TIFFTAG_SAMPLEFORMAT or TIFFTAG_DATATYPE, guessing pixeltype 
'UINT16'.
  LogLuvSetupDecode: Inappropriate photometric interpretation 32985 for SGILog 
compression; must be either LogLUV or LogL.
  ASAN:SIGSEGV
  =
  ==100013==ERROR: AddressSanitizer: SEGV on unknown address 0x7fba4f4096f6 (pc 
0x00463ce6 bp 0x7fff40bb34e0 sp 0x7fff40bb33b0 T0)
  #0 0x463ce5 in void vigra::StandardValueAccessor::set(unsigned short, unsigned short*&) 
const /usr/include/vigra/accessor.hxx:234
  #1 0x463ce5 in void vigra::detail::read_image_band, 
vigra::StandardValueAccessor >(vigra::Decoder*, 
vigra::BasicImageIterator, 
vigra::StandardValueAccessor) /usr/include/vigra/impex.hxx:86
  #2 0x463ce5 in void 
vigra::detail::importImage, vigra::StandardValueAccessor >(vigra::ImageImportInfo 
const&, vigra::BasicImageIterator, 
vigra::StandardValueAccessor, vigra::VigraTrueType) 
/usr/include/vigra/impex.hxx:212
  #3 0x60ef6c in void vigra::importImage, vigra::StandardValueAccessor 
>(vigra::ImageImportInfo const&, vigra::BasicImageIterator, vigra::StandardValueAccessor) 
/usr/include/vigra/impex.hxx:796
  #4 0x60ef6c in void vigra::importImage, vigra::StandardValueAccessor 
>(vigra::ImageImportInfo const&, std::pair, vigra::StandardValueAccessor >) 
/usr/include/vigra/impex.hxx:807
  #5 0x60ef6c in bool ResaveImage >, vigra::BasicImage > >(vigra::ImageImportInfo const&, 
vigra::ImageExportInfo&) /home/oren/hugin-2020.0.0/src/tools/verdandi.cpp:213
  #6 0x42154f in main /home/oren/hugin-2020.0.0/src/tools/verdandi.cpp:410
  #7 0x7fba574c682f in __libc_start_main 
(/lib/x86_64-linux-gnu/libc.so.6+0x2082f)
  #8 0x424878 in _start 
(/home/oren/hugin-2020.0.0/build/src/tools/verdandi+0x424878)

  AddressSanitizer can not provide additional info.
  SUMMARY: AddressSanitizer: SEGV /usr/include/vigra/accessor.hxx:234 void 
vigra::StandardValueAccessor::set(unsigned short, unsigned short*&) const
  ==100013==ABORTING

  
  Version : hugin (2020.0.0)
  OS : Ubuntu 20.04.1
  library : 
  - libvigraimpex-dev/focal,now 1.11.1+dfsg-7ubuntu1 amd64
  - libvigraimpex11/focal,now 1.11.1+dfsg-7ubuntu1 amd64

To manage notifications about this bug go to:
https://bugs.launchpad.net/hugin/+bug/1922039/+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 1907917] Re: Appdata update

2020-12-12 Thread Bruno Postle
The hugin fedora package is carrying a patch (since March 2015) that
overwrites the calibrate_lens_gui.appdata.xml file with this. @hub Any
idea if this is still needed?




  CC0-1.0
  calibrate_lens_gui.desktop
  
hugin.desktop
  


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

Title:
  Appdata update

Status in Hugin:
  New

Bug description:
  Here is a patch to update the appdata file that is missing the last
  release, and to address validation errors:

  • attribute-invalid :  width (800) did not match specified 
(1600) [http://hugin.sourceforge.net/screenshots/appdata/hugin-1.png]
  • attribute-invalid :  height (600) did not match specified 
(900) [http://hugin.sourceforge.net/screenshots/appdata/hugin-1.png]
  • attribute-invalid :  width (800) did not match specified 
(1600) [http://hugin.sourceforge.net/screenshots/appdata/hugin-2.png]
  • attribute-invalid :  height (600) did not match specified 
(900) [http://hugin.sourceforge.net/screenshots/appdata/hugin-2.png]
  • attribute-invalid :  width (800) did not match specified 
(1600) [http://hugin.sourceforge.net/screenshots/appdata/hugin-3.png]
  • attribute-invalid :  height (600) did not match specified 
(900) [http://hugin.sourceforge.net/screenshots/appdata/hugin-3.png]
  • attribute-invalid :  width (800) did not match specified 
(1600) [http://hugin.sourceforge.net/screenshots/appdata/hugin-4.png]
  • attribute-invalid :  height (600) did not match specified 
(900) [http://hugin.sourceforge.net/screenshots/appdata/hugin-4.png]
  • attribute-invalid :  width (800) did not match specified 
(1600) [http://hugin.sourceforge.net/screenshots/appdata/hugin-5.png]
  • attribute-invalid :  height (600) did not match specified 
(900) [http://hugin.sourceforge.net/screenshots/appdata/hugin-5.png]

To manage notifications about this bug go to:
https://bugs.launchpad.net/hugin/+bug/1907917/+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 1889191] [NEW] Patch to build with gcc-10.2.1

2020-07-28 Thread Bruno Postle
Public bug reported:

enblend 4.2 fails to build on fedora 33, presumably this is due to
changes between gcc-10.1 and gcc 10.2.

The attached patch fixes the build by adding "#include " to
various files, it also applies to the default branch (but I haven't
tested).

** Affects: enblend
 Importance: Undecided
 Status: New

** Patch added: "enblend-limits.patch"
   
https://bugs.launchpad.net/bugs/1889191/+attachment/5396524/+files/enblend-limits.patch

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

Title:
  Patch to build with gcc-10.2.1

Status in Enblend:
  New

Bug description:
  enblend 4.2 fails to build on fedora 33, presumably this is due to
  changes between gcc-10.1 and gcc 10.2.

  The attached patch fixes the build by adding "#include " to
  various files, it also applies to the default branch (but I haven't
  tested).

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


Re: [Hugin-devs] [Bug 1858272] [NEW] AppStream metadata in legacy format

2020-01-05 Thread Bruno Postle
This should now be fixed in the default branch

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

Title:
  AppStream metadata in legacy format

Status in Hugin:
  New

Bug description:
  Hugin's appstream data does not implement the current specification.
   
https://www.freedesktop.org/software/appstream/docs/chap-Metadata.html#sect-Metadata-GenericComponent

  It is installed in the legacy path /usr/share/appdata/ with obsolete
  format (toplevel node is ).

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


Re: [Hugin-devs] [Bug 1840798] [NEW] vertical line end point displaced

2019-08-20 Thread Bruno Postle
You have to disable-fine tune for this line unless the vertical feature
is exactly the same at the top as at the bottom. Otherwise, drag the
points into place after placing them.


On 20 August 2019 17:04:45 BST, Vegard Brenna wrote:
>
>I am trying to create a vertical line. When I click in the right window
>to position the bottom point, it appears 3-400 pixels off to the left.
>This is approx half way down a 20Mpix image.
>The behaviour is reproducible, as in happens all the time.

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

Title:
  vertical line end point displaced

Status in Hugin:
  New

Bug description:
  I am trying to create a vertical line. When I click in the right window to 
position the bottom point, it appears 3-400 pixels off to the left. This is 
approx half way down a 20Mpix image.
  The behaviour is reproducible, as in happens all the time.

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


Re: [Hugin-devs] [Bug 1770946] Re: Package Hugin as flatpak

2019-07-07 Thread Bruno Postle
I'm the fedora maintainer, so I'd like to know why it is crashing in
f29. But the first thing you should do is delete the ~/.hugin
preferences and see if that fixes it.

There are 2019.0 rpms for f29 in the panorama copr repository, here:
https://copr.fedorainfracloud.org/coprs/bpostle/panorama/

You can enable this repository like so:

  dnf copr enable bpostle/panorama

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

Title:
  Package Hugin as flatpak

Status in Hugin:
  Expired

Bug description:
  Hi,

  I would like to ask to package Hugin as a flatpak, which is a Linux
  distribution agnostic way of delivering software.

  The documentation about it can be found here:
  http://docs.flatpak.org/en/latest/

  That would bring several advantages for Linux users and developers,
  such as being able to use the latest version of the application on
  several distributions and different versions (old LTS or a just
  released one), it avoids dependency problems, it allows application
  sandboxing, and more:
  http://docs.flatpak.org/en/latest/introduction.html#target-audience

  
  Thanks

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


Re: [Hugin-devs] [Bug 1834767] Re: Current default fails to build

2019-07-02 Thread Bruno Postle
Hi Terry, I'm not sure if you have mercurial commit access. Use these
commands to commit your changes to your local repository, then try to
push any changes to the sourceforge repository:

  hg commit
  hg push

I have no idea if Christoph has abandoned or paused development. He has
only been quiet for a year or so, which doesn't seem like a _very_ long
time.

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

Title:
  Current default fails to build

Status in Enblend:
  New

Bug description:
  Attempting to build the current Enblend default source in Fedora 30, using 
rpmbuild.
  Build fails with the following message...

  In file included from 
/home/terry/rpmbuild/BUILD/enblend-4.3.0-1519hg-Source/src/enfuse.cc:188:
  /home/terry/rpmbuild/BUILD/enblend-4.3.0-1519hg-Source/src/enfuse.h: In 
function 'void enblend::enfuseMain(const FileNameList&, const 
std::__cxx11::list&, vigra::ImageExportInfo&, 
vigra::Rect2D&)':
  /home/terry/rpmbuild/BUILD/enblend-4.3.0-1519hg-Source/src/enfuse.h:1269:27: 
error: 'Error' in namespace 'Exiv2' does not name a type
   1269 | catch (Exiv2::Error& e) {
|   ^
  /home/terry/rpmbuild/BUILD/enblend-4.3.0-1519hg-Source/src/enfuse.h:1273:46: 
error: 'e' was not declared in this scope
   1273 | command << ": note: " << e.what() << "\n";
|  ^
  /home/terry/rpmbuild/BUILD/enblend-4.3.0-1519hg-Source/src/enfuse.h:1654:27: 
error: 'Error' in namespace 'Exiv2' does not name a type
   1654 | catch (Exiv2::Error& e) {
|   ^
  /home/terry/rpmbuild/BUILD/enblend-4.3.0-1519hg-Source/src/enfuse.h:1658:46: 
error: 'e' was not declared in this scope
   1658 | command << ": note: " << e.what() << "\n";
|  ^
  make[2]: *** [src/CMakeFiles/enfuse.dir/build.make:79: 
src/CMakeFiles/enfuse.dir/enfuse.cc.o] Error 1
  make[2]: Leaving directory 
'/home/terry/rpmbuild/BUILD/enblend-4.3.0-1519hg-Source'
  make[1]: *** [CMakeFiles/Makefile2:215: src/CMakeFiles/enfuse.dir/all] Error 2
  make[1]: Leaving directory 
'/home/terry/rpmbuild/BUILD/enblend-4.3.0-1519hg-Source'
  make: *** [Makefile:155: all] Error 2
  error: Bad exit status from /var/tmp/rpm-tmp.zxxB72 (%build)

  
  RPM build errors:
  Bad exit status from /var/tmp/rpm-tmp.zxxB72 (%build)

  Hope this helps.

  Cheers,
  Terry

To manage notifications about this bug go to:
https://bugs.launchpad.net/enblend/+bug/1834767/+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 1834991] [NEW] Applying a template sets image flags to grayscale

2019-07-01 Thread Bruno Postle
Public bug reported:

Steps to reproduce:

1. Load some RGB images in a new project
2. Apply a suitable template with File -> Apply template
3. Try and add another RGB image to the project

Hugin complains: "File [...] is a color image, but other images in
project are grayscale images. Hugin does not support this mixing.
Skipping this image."

Workaround is to save and open the project before adding new images.

** 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/1834991

Title:
  Applying a template sets image flags to grayscale

Status in Hugin:
  New

Bug description:
  Steps to reproduce:

  1. Load some RGB images in a new project
  2. Apply a suitable template with File -> Apply template
  3. Try and add another RGB image to the project

  Hugin complains: "File [...] is a color image, but other images in
  project are grayscale images. Hugin does not support this mixing.
  Skipping this image."

  Workaround is to save and open the project before adding new images.

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


Re: [Hugin-devs] [Bug 1834767] Re: Current default fails to build

2019-07-01 Thread Bruno Postle
I think the docs problem is a fedora issue. I've given up building the
enblend docs as they break more than anything else

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

Title:
  Current default fails to build

Status in Enblend:
  New

Bug description:
  Attempting to build the current Enblend default source in Fedora 30, using 
rpmbuild.
  Build fails with the following message...

  In file included from 
/home/terry/rpmbuild/BUILD/enblend-4.3.0-1519hg-Source/src/enfuse.cc:188:
  /home/terry/rpmbuild/BUILD/enblend-4.3.0-1519hg-Source/src/enfuse.h: In 
function 'void enblend::enfuseMain(const FileNameList&, const 
std::__cxx11::list&, vigra::ImageExportInfo&, 
vigra::Rect2D&)':
  /home/terry/rpmbuild/BUILD/enblend-4.3.0-1519hg-Source/src/enfuse.h:1269:27: 
error: 'Error' in namespace 'Exiv2' does not name a type
   1269 | catch (Exiv2::Error& e) {
|   ^
  /home/terry/rpmbuild/BUILD/enblend-4.3.0-1519hg-Source/src/enfuse.h:1273:46: 
error: 'e' was not declared in this scope
   1273 | command << ": note: " << e.what() << "\n";
|  ^
  /home/terry/rpmbuild/BUILD/enblend-4.3.0-1519hg-Source/src/enfuse.h:1654:27: 
error: 'Error' in namespace 'Exiv2' does not name a type
   1654 | catch (Exiv2::Error& e) {
|   ^
  /home/terry/rpmbuild/BUILD/enblend-4.3.0-1519hg-Source/src/enfuse.h:1658:46: 
error: 'e' was not declared in this scope
   1658 | command << ": note: " << e.what() << "\n";
|  ^
  make[2]: *** [src/CMakeFiles/enfuse.dir/build.make:79: 
src/CMakeFiles/enfuse.dir/enfuse.cc.o] Error 1
  make[2]: Leaving directory 
'/home/terry/rpmbuild/BUILD/enblend-4.3.0-1519hg-Source'
  make[1]: *** [CMakeFiles/Makefile2:215: src/CMakeFiles/enfuse.dir/all] Error 2
  make[1]: Leaving directory 
'/home/terry/rpmbuild/BUILD/enblend-4.3.0-1519hg-Source'
  make: *** [Makefile:155: all] Error 2
  error: Bad exit status from /var/tmp/rpm-tmp.zxxB72 (%build)

  
  RPM build errors:
  Bad exit status from /var/tmp/rpm-tmp.zxxB72 (%build)

  Hope this helps.

  Cheers,
  Terry

To manage notifications about this bug go to:
https://bugs.launchpad.net/enblend/+bug/1834767/+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 1834767] Re: Current default fails to build

2019-06-30 Thread Bruno Postle
Hi Terry, this seems similar to the exiv2 bug you found in Hugin, i.e:
#include  should now be #include 

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

Title:
  Current default fails to build

Status in Enblend:
  New

Bug description:
  Attempting to build the current Enblend default source in Fedora 30, using 
rpmbuild.
  Build fails with the following message...

  In file included from 
/home/terry/rpmbuild/BUILD/enblend-4.3.0-1519hg-Source/src/enfuse.cc:188:
  /home/terry/rpmbuild/BUILD/enblend-4.3.0-1519hg-Source/src/enfuse.h: In 
function 'void enblend::enfuseMain(const FileNameList&, const 
std::__cxx11::list&, vigra::ImageExportInfo&, 
vigra::Rect2D&)':
  /home/terry/rpmbuild/BUILD/enblend-4.3.0-1519hg-Source/src/enfuse.h:1269:27: 
error: 'Error' in namespace 'Exiv2' does not name a type
   1269 | catch (Exiv2::Error& e) {
|   ^
  /home/terry/rpmbuild/BUILD/enblend-4.3.0-1519hg-Source/src/enfuse.h:1273:46: 
error: 'e' was not declared in this scope
   1273 | command << ": note: " << e.what() << "\n";
|  ^
  /home/terry/rpmbuild/BUILD/enblend-4.3.0-1519hg-Source/src/enfuse.h:1654:27: 
error: 'Error' in namespace 'Exiv2' does not name a type
   1654 | catch (Exiv2::Error& e) {
|   ^
  /home/terry/rpmbuild/BUILD/enblend-4.3.0-1519hg-Source/src/enfuse.h:1658:46: 
error: 'e' was not declared in this scope
   1658 | command << ": note: " << e.what() << "\n";
|  ^
  make[2]: *** [src/CMakeFiles/enfuse.dir/build.make:79: 
src/CMakeFiles/enfuse.dir/enfuse.cc.o] Error 1
  make[2]: Leaving directory 
'/home/terry/rpmbuild/BUILD/enblend-4.3.0-1519hg-Source'
  make[1]: *** [CMakeFiles/Makefile2:215: src/CMakeFiles/enfuse.dir/all] Error 2
  make[1]: Leaving directory 
'/home/terry/rpmbuild/BUILD/enblend-4.3.0-1519hg-Source'
  make: *** [Makefile:155: all] Error 2
  error: Bad exit status from /var/tmp/rpm-tmp.zxxB72 (%build)

  
  RPM build errors:
  Bad exit status from /var/tmp/rpm-tmp.zxxB72 (%build)

  Hope this helps.

  Cheers,
  Terry

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


Re: [Hugin-devs] [Bug 1829309] [NEW] Building current default in Fedora 30 fails due to Python plugins

2019-05-16 Thread Bruno Postle
Yes, `/usr/bin/env python` really doesn't work on a system with both
versions of python installed, so the fedora build system refuses to
proceed.

The fedora rpm replaces this with `/usr/bin/python3` before the build to
force python3 (since the hsi stuff is linked to python3, nothing else
makes sense).

Hugin should drop support for python2.


On 16 May 2019 00:33:36 BST, tduell wrote:

>*** ERROR: ambiguous python shebang in
>/usr/share/hugin/data/plugins/shooting_pattern.py: #!/usr/bin/env
>python. Change it to python3 (or python2) explicitly.
>**CT/dual_use.py: #!/usr/bin/env
>python. Change it to python3 (or python2) explicitly.

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

Title:
  Building current default in Fedora 30 fails due to Python plugins

Status in Hugin:
  New

Bug description:
  Building current hugin default 8203 01e87b730bb3 in Fedora 30, fails
  with the following message...

  Bytecompiling .py files below 
/home/terry/rpmbuild/BUILDROOT/hugin-2019.1.0-0.1.20190516hg.fc30.x86_64/usr/lib/debug/usr/lib64/python2.7
 using /usr/bin/python2.7
  Bytecompiling .py files below 
/home/terry/rpmbuild/BUILDROOT/hugin-2019.1.0-0.1.20190516hg.fc30.x86_64/usr/lib64/python2.7
 using /usr/bin/python2.7
  + /usr/lib/rpm/brp-python-hardlink
  + /usr/lib/rpm/redhat/brp-mangle-shebangs
  *** ERROR: ambiguous python shebang in 
/usr/share/hugin/data/plugins/shooting_pattern.py: #!/usr/bin/env python. 
Change it to python3 (or python2) explicitly.
  *** ERROR: ambiguous python shebang in 
/usr/share/hugin/data/plugins/top_five.py: #!/usr/bin/env python. Change it to 
python3 (or python2) explicitly.
  *** ERROR: ambiguous python shebang in 
/usr/share/hugin/data/plugins/crop_cp.py: #!/usr/bin/env python. Change it to 
python3 (or python2) explicitly.
  *** ERROR: ambiguous python shebang in /usr/share/hugin/data/plugins/woa.py: 
#!/usr/bin/env python. Change it to python3 (or python2) explicitly.
  *** ERROR: ambiguous python shebang in 
/usr/share/hugin/data/plugins-templates/plugin_skeleton.py: #!/usr/bin/env 
python. Change it to python3 (or python2) explicitly.
  *** ERROR: ambiguous python shebang in 
/usr/share/hugin/data/plugins-templates/dual_use.py: #!/usr/bin/env python. 
Change it to python3 (or python2) explicitly.
  *** ERROR: ambiguous python shebang in 
/usr/lib64/python2.7/site-packages/hpi.py: #!/usr/bin/env python. Change it to 
python3 (or python2) explicitly.
  error: Bad exit status from /var/tmp/rpm-tmp.eEpDLf (%install)

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


Re: [Hugin-devs] [Bug 1828925] Re: Hugin build fails in fedora 30

2019-05-15 Thread Bruno Postle
On 15 May 2019 00:08:29 BST, tduell wrote:
>Hello Bruno,

>Are you seeing the same build error?

Hi Terry, I haven't had a chance to test myself, but fedora rebuilds
every package every few days to check for this kind of thing, so I got
an automatic email telling me it was broken - this is how I know that
the problem is the exiv2 update not gcc.

[mailing directly because I'm at work and can't remember my launchpad
login]

-- 
Bruno

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

Title:
  Hugin build fails in fedora 30

Status in Hugin:
  New

Bug description:
  Building hugin snapshot 8199:62b0662d5bee in Fedora 30 produces the
  following error...

  
"/home/terry/rpmbuild/BUILD/hugin-2019.1.0/src/hugin_base/panodata/SrcPanoImage.cpp:339:30:
 error: expected '{' before '&' token
  make[2]: *** [src/hugin_base/CMakeFiles/huginbase.dir/build.make:651: 
src/hugin_base/CMakeFiles/huginbase.dir/panodata/SrcPanoImage.cpp.o] 
  Error 1"

  The same source code built without error in Fedora 29.
  I believe Fedora 30 uses GCC 9.1

To manage notifications about this bug go to:
https://bugs.launchpad.net/hugin/+bug/1828925/+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 1828925] Re: Hugin build fails in fedora 30

2019-05-14 Thread Bruno Postle
It appears to be because fedora exiv2 went from 0.27.0 to 0.27.1 a few
days ago.

gcc went from 9.0.1 to 9.1.1 a few days before, and this was ok:
https://apps.fedoraproject.org/koschei/package/hugin?collection=f30

I had a look at the exiv2 changelog and didn't see anything obvious.

Nothing is significantly different in the build log, the cmake output
and compiler flags are the same as before.

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

Title:
  Hugin build fails in fedora 30

Status in Hugin:
  New

Bug description:
  Building hugin snapshot 8199:62b0662d5bee in Fedora 30 produces the
  following error...

  
"/home/terry/rpmbuild/BUILD/hugin-2019.1.0/src/hugin_base/panodata/SrcPanoImage.cpp:339:30:
 error: expected '{' before '&' token
  make[2]: *** [src/hugin_base/CMakeFiles/huginbase.dir/build.make:651: 
src/hugin_base/CMakeFiles/huginbase.dir/panodata/SrcPanoImage.cpp.o] 
  Error 1"

  The same source code built without error in Fedora 29.
  I believe Fedora 30 uses GCC 9.1

To manage notifications about this bug go to:
https://bugs.launchpad.net/hugin/+bug/1828925/+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 1819928] Re: it should link against libwx_gtk2u_aui-3.0

2019-03-22 Thread Bruno Postle
The fedora problem is with the 2018.0.0 release, this is something that
has changed in cmake.

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

Title:
  it should link against libwx_gtk2u_aui-3.0

Status in Hugin:
  Incomplete

Bug description:
  Trying to build the   version it fails with lots of undefined references like
  wxGLCanvas::GetClassInfo() const

  It should build against additional libraries like  libwx_gtk2u_aui-3.0

To manage notifications about this bug go to:
https://bugs.launchpad.net/hugin/+bug/1819928/+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 1819928] Re: it should link against libwx_gtk2u_aui-3.0

2019-03-22 Thread Bruno Postle
We have the same problem on fedora, all releases. Hugin no longer builds when 
cmake is upgraded from 3.13.4 to 3.14.0:
https://bugzilla.redhat.com/show_bug.cgi?id=1690947

** Bug watch added: Red Hat Bugzilla #1690947
   https://bugzilla.redhat.com/show_bug.cgi?id=1690947

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

Title:
  it should link against libwx_gtk2u_aui-3.0

Status in Hugin:
  Incomplete

Bug description:
  Trying to build the   version it fails with lots of undefined references like
  wxGLCanvas::GetClassInfo() const

  It should build against additional libraries like  libwx_gtk2u_aui-3.0

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

2017-07-08 Thread Bruno Postle
I'm attaching a set of ten test cases that reproduce this bug. They are
all small images so the whole thing runs in five seconds on this
machine.

This has been set up so correct output should be ten identical 100%
white images, on this machine I get black artefacts in every output.

** Attachment added: "enblend-test.tar.gz"
   
https://bugs.launchpad.net/enblend/+bug/721136/+attachment/4911436/+files/enblend-test.tar.gz

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


Re: [Hugin-devs] [Bug 1475448] Re: DVI output fails on SMP build

2015-07-26 Thread Bruno Postle
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Can confirm this is (probably) fixed with default branch, 
`make all pdf -j2` just completed ok four times in a row.

- -- 
Bruno
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iEYEARECAAYFAlW1WFEACgkQFqOhwCjyCLoDfQCeLtXZQaOzdb5GwiUfHZrbvMCl
6iMAmwdV7cKw+syNWhhvOzr901/gY+GF
=cm8N
-END PGP SIGNATURE-

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

Title:
  DVI output fails on SMP build

Status in Enblend:
  Fix Committed

Bug description:
  Basically the default 'make' target builds the binaries, man pages,
  PS, DVI and HTML docs, but the DVI step fails randomly half the time
  when using the make -j2 option to build in parallel (and 3/4 of the
  time with -j4).

  The result is that a local build is fine, but enblend built in the
  fedora build system is not. I can force fedora to build with a single
  thread, but this slows things down, and this problem will catch out
  other packagers in the future.

  A workaround would be to just build the binaries and man pages in the
  default target and let people build the DVI/PDF/HTML docs separately
  as needed.

To manage notifications about this bug go to:
https://bugs.launchpad.net/enblend/+bug/1475448/+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 1475448] [NEW] DVI output fails on SMP build

2015-07-16 Thread Bruno Postle
Public bug reported:

Basically the default 'make' target builds the binaries, man pages, PS,
DVI and HTML docs, but the DVI step fails randomly half the time when
using the make -j2 option to build in parallel (and 3/4 of the time with
-j4).

The result is that a local build is fine, but enblend built in the
fedora build system is not. I can force fedora to build with a single
thread, but this slows things down, and this problem will catch out
other packagers in the future.

A workaround would be to just build the binaries and man pages in the
default target and let people build the DVI/PDF/HTML docs separately as
needed.

** Affects: enblend
 Importance: Undecided
 Status: New

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

Title:
  DVI output fails on SMP build

Status in Enblend:
  New

Bug description:
  Basically the default 'make' target builds the binaries, man pages,
  PS, DVI and HTML docs, but the DVI step fails randomly half the time
  when using the make -j2 option to build in parallel (and 3/4 of the
  time with -j4).

  The result is that a local build is fine, but enblend built in the
  fedora build system is not. I can force fedora to build with a single
  thread, but this slows things down, and this problem will catch out
  other packagers in the future.

  A workaround would be to just build the binaries and man pages in the
  default target and let people build the DVI/PDF/HTML docs separately
  as needed.

To manage notifications about this bug go to:
https://bugs.launchpad.net/enblend/+bug/1475448/+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 1468520] Re: make dist fails

2015-07-16 Thread Bruno Postle
The patch in #5 does force an 'all' before 'dist', so at least there is
no error, you should apply. It doesn't matter too much as only a handful
of people are ever going to need the 'dist' target.

Personally I would like to be able to create a tarball without
compiling, as compiling slows down the process of making snapshot rpm
packages: currently I update mercurial, make a tarball, update the rpm
.spec file, then build enblend packages for multiple platforms (which is
automated) - if creating the tarball was straightforward then the whole
thing would only take five minutes attention.

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

Title:
  make dist fails

Status in Enblend:
  Incomplete

Bug description:
  I'm trying to make a tarball from the default branch so I can update
  the fedora package but `make dist` fails:

  $ make dist
  make  dist-gzip am__post_remove_distdir='@:'
  make[1]: Entering directory '/home/bruno/src/enblend'
  if test -d enblend-enfuse-4.2-add32106f8f5; then find 
enblend-enfuse-4.2-add32106f8f5 -type d ! -perm -200 -exec chmod u+w {} ';' 
 rm -rf enblend-enfuse-4.2-add32106f8f5 || { sleep 5  rm -rf 
enblend-enfuse-4.2-add32106f8f5; }; else :; fi
  test -d enblend-enfuse-4.2-add32106f8f5 || mkdir 
enblend-enfuse-4.2-add32106f8f5
   (cd share  make  top_distdir=../enblend-enfuse-4.2-add32106f8f5 
distdir=../enblend-enfuse-4.2-add32106f8f5/share \
   am__remove_distdir=: am__skip_length_check=: am__skip_mode_fix=: distdir)
  make[2]: Entering directory '/home/bruno/src/enblend/share'
   (cd enfuse  make  top_distdir=../../enblend-enfuse-4.2-add32106f8f5 
distdir=../../enblend-enfuse-4.2-add32106f8f5/share/enfuse \
   am__remove_distdir=: am__skip_length_check=: am__skip_mode_fix=: distdir)
  make[3]: Entering directory '/home/bruno/src/enblend/share/enfuse'
  make[3]: *** No rule to make target 'distdir'.  Stop.
  make[3]: Leaving directory '/home/bruno/src/enblend/share/enfuse'
  Makefile:489: recipe for target 'distdir' failed
  make[2]: *** [distdir] Error 1
  make[2]: Leaving directory '/home/bruno/src/enblend/share'
  Makefile:548: recipe for target 'distdir' failed
  make[1]: *** [distdir] Error 1
  make[1]: Leaving directory '/home/bruno/src/enblend'
  Makefile:647: recipe for target 'dist' failed
  make: *** [dist] Error 2

  This is fedora f22
  automake-1.15
  autoconf-2.69

  `./configure  make` works ok, so does `cmake .  make
  package_source`

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


Re: [Hugin-devs] [Bug 1468520] Re: make dist fails

2015-07-14 Thread Bruno Postle
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

- -BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Starting with a clean checkout:

make -f Makefile.scm
mkdir BUILD
cd BUILD
../configure
make dist

This tries to compile enblend/enfuse, but fails with:
../../src/enblend.cc:81:23: fatal error: signature.h: No such file or directory
..and:
No rule to make target 'layer_selection/liblayersel.a'

If I then just do this it all works fine:

make
make dist

- -BEGIN PGP SIGNATURE-
Version: GnuPG v1

iEYEARECAAYFAlWlkDsACgkQFqOhwCjyCLqojACeOF4KHAfXszmSyFt3h+deN6k0
pD4AoJ/a82lYQtOcogHUVs/vX0TjdrYI
=fAJy
- -END PGP SIGNATURE-
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iEYEARECAAYFAlWlksYACgkQFqOhwCjyCLpejwCfUsABlhJlbM/zkayxdM0Ay6F5
CK0An0hsr9q69UgUz8uhltzUpzq2noSF
=+upu
-END PGP SIGNATURE-

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

Title:
  make dist fails

Status in Enblend:
  Incomplete

Bug description:
  I'm trying to make a tarball from the default branch so I can update
  the fedora package but `make dist` fails:

  $ make dist
  make  dist-gzip am__post_remove_distdir='@:'
  make[1]: Entering directory '/home/bruno/src/enblend'
  if test -d enblend-enfuse-4.2-add32106f8f5; then find 
enblend-enfuse-4.2-add32106f8f5 -type d ! -perm -200 -exec chmod u+w {} ';' 
 rm -rf enblend-enfuse-4.2-add32106f8f5 || { sleep 5  rm -rf 
enblend-enfuse-4.2-add32106f8f5; }; else :; fi
  test -d enblend-enfuse-4.2-add32106f8f5 || mkdir 
enblend-enfuse-4.2-add32106f8f5
   (cd share  make  top_distdir=../enblend-enfuse-4.2-add32106f8f5 
distdir=../enblend-enfuse-4.2-add32106f8f5/share \
   am__remove_distdir=: am__skip_length_check=: am__skip_mode_fix=: distdir)
  make[2]: Entering directory '/home/bruno/src/enblend/share'
   (cd enfuse  make  top_distdir=../../enblend-enfuse-4.2-add32106f8f5 
distdir=../../enblend-enfuse-4.2-add32106f8f5/share/enfuse \
   am__remove_distdir=: am__skip_length_check=: am__skip_mode_fix=: distdir)
  make[3]: Entering directory '/home/bruno/src/enblend/share/enfuse'
  make[3]: *** No rule to make target 'distdir'.  Stop.
  make[3]: Leaving directory '/home/bruno/src/enblend/share/enfuse'
  Makefile:489: recipe for target 'distdir' failed
  make[2]: *** [distdir] Error 1
  make[2]: Leaving directory '/home/bruno/src/enblend/share'
  Makefile:548: recipe for target 'distdir' failed
  make[1]: *** [distdir] Error 1
  make[1]: Leaving directory '/home/bruno/src/enblend'
  Makefile:647: recipe for target 'dist' failed
  make: *** [dist] Error 2

  This is fedora f22
  automake-1.15
  autoconf-2.69

  `./configure  make` works ok, so does `cmake .  make
  package_source`

To manage notifications about this bug go to:
https://bugs.launchpad.net/enblend/+bug/1468520/+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 1468520] Re: make dist fails

2015-06-28 Thread Bruno Postle
Just to confirm, I see the problem with a clean tree and 'make all'
followed by 'make dist':

hg pull  hg up  hg revert --all
make -f Makefile.scm
./configure
make
make dist

It seems that $(srcdir) is being set to an empty string:

cd share
make distdir
cp: cannot create regular file ‘/Makefile.am’: Permission denied
Makefile:488: recipe for target 'distdir' failed

ah, enblend doesn't support an in-tree build, this _does_ work and
builds the docs too:

make distclean
hg revert --all
mkdir BUILD
cd BUILD
../configure
make
make dist

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

Title:
  make dist fails

Status in Enblend:
  New

Bug description:
  I'm trying to make a tarball from the default branch so I can update
  the fedora package but `make dist` fails:

  $ make dist
  make  dist-gzip am__post_remove_distdir='@:'
  make[1]: Entering directory '/home/bruno/src/enblend'
  if test -d enblend-enfuse-4.2-add32106f8f5; then find 
enblend-enfuse-4.2-add32106f8f5 -type d ! -perm -200 -exec chmod u+w {} ';' 
 rm -rf enblend-enfuse-4.2-add32106f8f5 || { sleep 5  rm -rf 
enblend-enfuse-4.2-add32106f8f5; }; else :; fi
  test -d enblend-enfuse-4.2-add32106f8f5 || mkdir 
enblend-enfuse-4.2-add32106f8f5
   (cd share  make  top_distdir=../enblend-enfuse-4.2-add32106f8f5 
distdir=../enblend-enfuse-4.2-add32106f8f5/share \
   am__remove_distdir=: am__skip_length_check=: am__skip_mode_fix=: distdir)
  make[2]: Entering directory '/home/bruno/src/enblend/share'
   (cd enfuse  make  top_distdir=../../enblend-enfuse-4.2-add32106f8f5 
distdir=../../enblend-enfuse-4.2-add32106f8f5/share/enfuse \
   am__remove_distdir=: am__skip_length_check=: am__skip_mode_fix=: distdir)
  make[3]: Entering directory '/home/bruno/src/enblend/share/enfuse'
  make[3]: *** No rule to make target 'distdir'.  Stop.
  make[3]: Leaving directory '/home/bruno/src/enblend/share/enfuse'
  Makefile:489: recipe for target 'distdir' failed
  make[2]: *** [distdir] Error 1
  make[2]: Leaving directory '/home/bruno/src/enblend/share'
  Makefile:548: recipe for target 'distdir' failed
  make[1]: *** [distdir] Error 1
  make[1]: Leaving directory '/home/bruno/src/enblend'
  Makefile:647: recipe for target 'dist' failed
  make: *** [dist] Error 2

  This is fedora f22
  automake-1.15
  autoconf-2.69

  `./configure  make` works ok, so does `cmake .  make
  package_source`

To manage notifications about this bug go to:
https://bugs.launchpad.net/enblend/+bug/1468520/+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 1468524] [NEW] convert -3 error building docs

2015-06-24 Thread Bruno Postle
Public bug reported:

This code in configure.ac tries to substitute 'convert' for 'tiff2ps' if
tiff2ps isn't found:

AC_PATH_PROG(TIFF2PS, tiff2ps, false)
if test $TIFF2PS = false; then
if test $CONVERT != false; then
AC_MSG_WARN(cannot find tiff2ps; will substitute convert)
TIFF2PS=$CONVERT
TIFF2PS_FLAGS=
else
AC_MSG_WARN(cannot find tiff2ps; will not be able to build PostScript 
documentation)
can_build_doc=no
missing_for_doc=$missing_for_doc tiff2ps
fi
fi

..but then this fails calling `convert -3` which isn't a valid convert
command.

Other than that, once I have all the right dependencies installed, I can
now successfully build html, dvi, ps and pdf docs - It's a long time
since this worked on fedora!

** Affects: enblend
 Importance: Undecided
 Status: New

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

Title:
  convert -3 error building docs

Status in Enblend:
  New

Bug description:
  This code in configure.ac tries to substitute 'convert' for 'tiff2ps'
  if tiff2ps isn't found:

  AC_PATH_PROG(TIFF2PS, tiff2ps, false)
  if test $TIFF2PS = false; then
  if test $CONVERT != false; then
  AC_MSG_WARN(cannot find tiff2ps; will substitute convert)
  TIFF2PS=$CONVERT
  TIFF2PS_FLAGS=
  else
  AC_MSG_WARN(cannot find tiff2ps; will not be able to build PostScript 
documentation)
  can_build_doc=no
  missing_for_doc=$missing_for_doc tiff2ps
  fi
  fi

  ..but then this fails calling `convert -3` which isn't a valid convert
  command.

  Other than that, once I have all the right dependencies installed, I
  can now successfully build html, dvi, ps and pdf docs - It's a long
  time since this worked on fedora!

To manage notifications about this bug go to:
https://bugs.launchpad.net/enblend/+bug/1468524/+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 1468520] [NEW] make dist fails

2015-06-24 Thread Bruno Postle
Public bug reported:

I'm trying to make a tarball from the default branch so I can update the
fedora package but `make dist` fails:

$ make dist
make  dist-gzip am__post_remove_distdir='@:'
make[1]: Entering directory '/home/bruno/src/enblend'
if test -d enblend-enfuse-4.2-add32106f8f5; then find 
enblend-enfuse-4.2-add32106f8f5 -type d ! -perm -200 -exec chmod u+w {} ';' 
 rm -rf enblend-enfuse-4.2-add32106f8f5 || { sleep 5  rm -rf 
enblend-enfuse-4.2-add32106f8f5; }; else :; fi
test -d enblend-enfuse-4.2-add32106f8f5 || mkdir 
enblend-enfuse-4.2-add32106f8f5
 (cd share  make  top_distdir=../enblend-enfuse-4.2-add32106f8f5 
distdir=../enblend-enfuse-4.2-add32106f8f5/share \
 am__remove_distdir=: am__skip_length_check=: am__skip_mode_fix=: distdir)
make[2]: Entering directory '/home/bruno/src/enblend/share'
 (cd enfuse  make  top_distdir=../../enblend-enfuse-4.2-add32106f8f5 
distdir=../../enblend-enfuse-4.2-add32106f8f5/share/enfuse \
 am__remove_distdir=: am__skip_length_check=: am__skip_mode_fix=: distdir)
make[3]: Entering directory '/home/bruno/src/enblend/share/enfuse'
make[3]: *** No rule to make target 'distdir'.  Stop.
make[3]: Leaving directory '/home/bruno/src/enblend/share/enfuse'
Makefile:489: recipe for target 'distdir' failed
make[2]: *** [distdir] Error 1
make[2]: Leaving directory '/home/bruno/src/enblend/share'
Makefile:548: recipe for target 'distdir' failed
make[1]: *** [distdir] Error 1
make[1]: Leaving directory '/home/bruno/src/enblend'
Makefile:647: recipe for target 'dist' failed
make: *** [dist] Error 2

This is fedora f22
automake-1.15
autoconf-2.69

`./configure  make` works ok, so does `cmake .  make package_source`

** Affects: enblend
 Importance: Undecided
 Status: New

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

Title:
  make dist fails

Status in Enblend:
  New

Bug description:
  I'm trying to make a tarball from the default branch so I can update
  the fedora package but `make dist` fails:

  $ make dist
  make  dist-gzip am__post_remove_distdir='@:'
  make[1]: Entering directory '/home/bruno/src/enblend'
  if test -d enblend-enfuse-4.2-add32106f8f5; then find 
enblend-enfuse-4.2-add32106f8f5 -type d ! -perm -200 -exec chmod u+w {} ';' 
 rm -rf enblend-enfuse-4.2-add32106f8f5 || { sleep 5  rm -rf 
enblend-enfuse-4.2-add32106f8f5; }; else :; fi
  test -d enblend-enfuse-4.2-add32106f8f5 || mkdir 
enblend-enfuse-4.2-add32106f8f5
   (cd share  make  top_distdir=../enblend-enfuse-4.2-add32106f8f5 
distdir=../enblend-enfuse-4.2-add32106f8f5/share \
   am__remove_distdir=: am__skip_length_check=: am__skip_mode_fix=: distdir)
  make[2]: Entering directory '/home/bruno/src/enblend/share'
   (cd enfuse  make  top_distdir=../../enblend-enfuse-4.2-add32106f8f5 
distdir=../../enblend-enfuse-4.2-add32106f8f5/share/enfuse \
   am__remove_distdir=: am__skip_length_check=: am__skip_mode_fix=: distdir)
  make[3]: Entering directory '/home/bruno/src/enblend/share/enfuse'
  make[3]: *** No rule to make target 'distdir'.  Stop.
  make[3]: Leaving directory '/home/bruno/src/enblend/share/enfuse'
  Makefile:489: recipe for target 'distdir' failed
  make[2]: *** [distdir] Error 1
  make[2]: Leaving directory '/home/bruno/src/enblend/share'
  Makefile:548: recipe for target 'distdir' failed
  make[1]: *** [distdir] Error 1
  make[1]: Leaving directory '/home/bruno/src/enblend'
  Makefile:647: recipe for target 'dist' failed
  make: *** [dist] Error 2

  This is fedora f22
  automake-1.15
  autoconf-2.69

  `./configure  make` works ok, so does `cmake .  make
  package_source`

To manage notifications about this bug go to:
https://bugs.launchpad.net/enblend/+bug/1468520/+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 1467678] Re: nona segfaults with PNG and TIFF output

2015-06-23 Thread Bruno Postle
Thanks, that works.

The current 2015.0 branch (dc7eb38fe1d5) patched with 5f45958ae420 now
renders TIFF without crashing.

(this is a 2015.0 bug. 2014.0 is fine, I even rebuilt it to be sure
there is no problem with the build environment. All this is with the
same vigra impex 1.10.0 library)

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

Title:
  nona segfaults with PNG and TIFF output

Status in Hugin - Panorama Tools GUI:
  New

Bug description:
  System: fedora f22 x86_64
  hugin 2015.0.0 rc1 c48252eb571f
  libtiff-4.0.3
  libpng-1.6.16
  libjpeg-turbo-1.4.0
  vigra-1.10.0

  I'm getting a segfault from nona with PNG and TIFF output, JPEG is
  fine.

  This is a simple single image project with JPEG input:

nona -i 0 -m TIFF  -o junk project.pto
Segmentation fault (core dumped)

  Result is the same with or without -m parameter and with multiple photo 
projects.
  OMP_NUM_THREADS=1 doesn't help. I don't have a suitable GPU so I can't test 
that.

  Thread 1 (Thread 0x7f100c213900 (LWP 3761)):
  #0  0x7f100bbabbc8 in void vigra::detail::exportImagevigra::Diff2D, 
vigra::MultiImageVectorMaskAccessor4vigra::ConstBasicImageIteratorvigra::RGBValueunsigned
 char, 0u, 1u, 2u, vigra::RGBValueunsigned char, 0u, 1u, 2u**, 
vigra::RGBAccessorvigra::RGBValueunsigned char, 0u, 1u, 2u , 
vigra::ConstBasicImageIteratorunsigned char, unsigned char**, 
vigra::StandardConstValueAccessorunsigned char  (vigra::Diff2D, 
vigra::Diff2D, 
vigra::MultiImageVectorMaskAccessor4vigra::ConstBasicImageIteratorvigra::RGBValueunsigned
 char, 0u, 1u, 2u, vigra::RGBValueunsigned char, 0u, 1u, 2u**, 
vigra::RGBAccessorvigra::RGBValueunsigned char, 0u, 1u, 2u , 
vigra::ConstBasicImageIteratorunsigned char, unsigned char**, 
vigra::StandardConstValueAccessorunsigned char , vigra::ImageExportInfo 
const, vigra::VigraFalseType)
  () from /usr/lib64/hugin/libhuginbase.so.0.0
  No symbol table info available.
  #1  0x7f100bb9760a in void 
vigra::exportImageAlphavigra::ConstBasicImageIteratorvigra::RGBValueunsigned 
char, 0u, 1u, 2u, vigra::RGBValueunsigned char, 0u, 1u, 2u**, 
vigra::RGBAccessorvigra::RGBValueunsigned char, 0u, 1u, 2u , 
vigra::ConstBasicImageIteratorunsigned char, unsigned char**, 
vigra::StandardConstValueAccessorunsigned char 
(vigra::triplevigra::ConstBasicImageIteratorvigra::RGBValueunsigned char, 
0u, 1u, 2u, vigra::RGBValueunsigned char, 0u, 1u, 2u**, 
vigra::ConstBasicImageIteratorvigra::RGBValueunsigned char, 0u, 1u, 2u, 
vigra::RGBValueunsigned char, 0u, 1u, 2u**, 
vigra::RGBAccessorvigra::RGBValueunsigned char, 0u, 1u, 2u  , 
std::pairvigra::ConstBasicImageIteratorunsigned char, unsigned char**, 
vigra::StandardConstValueAccessorunsigned char , vigra::ImageExportInfo 
const, vigra::VigraFalseType) [clone .isra.915] [clone .constprop.1312] () 
from /usr/lib64/hugin/libhuginbase.so.0.0
  No symbol table info available.
  #2  0x7f100bbbe152 in 
HuginBase::Nona::WeightedStitchervigra::BasicImagevigra::RGBValueunsigned 
char, 0u, 1u, 2u, std::allocatorvigra::RGBValueunsigned char, 0u, 1u, 2u  
, vigra::BasicImageunsigned char, std::allocatorunsigned char  
::stitch(HuginBase::PanoramaOptions const, std::setunsigned int, 
std::lessunsigned int, std::allocatorunsigned int , std::string const, 
HuginBase::Nona::SingleImageRemappervigra::BasicImagevigra::RGBValueunsigned 
char, 0u, 1u, 2u, std::allocatorvigra::RGBValueunsigned char, 0u, 1u, 2u  
, vigra::BasicImageunsigned char, std::allocatorunsigned char  , 
std::mapstd::string, std::string, std::lessstd::string, 
std::allocatorstd::pairstd::string const, std::string   const) () from 
/usr/lib64/hugin/libhuginbase.so.0.0
  No symbol table info available.
  #3  0x7f100bb981e9 in 
HuginBase::Nona::stitchPanoRGB_8_16(HuginBase::PanoramaData const, 
HuginBase::PanoramaOptions const, AppBase::ProgressDisplay*, std::string 
const, std::setunsigned int, std::lessunsigned int, std::allocatorunsigned 
int  const, char const*, std::mapstd::string, std::string, 
std::lessstd::string, std::allocatorstd::pairstd::string const, 
std::string   const) ()
 from /usr/lib64/hugin/libhuginbase.so.0.0
  No symbol table info available.
  #4  0x7f100bcd2c9a in 
HuginBase::Nona::stitchPanorama(HuginBase::PanoramaData const, 
HuginBase::PanoramaOptions const, AppBase::ProgressDisplay*, std::string 
const, std::setunsigned int, std::lessunsigned int, std::allocatorunsigned 
int  const, std::mapstd::string, std::string, std::lessstd::string, 
std::allocatorstd::pairstd::string const, std::string   const) ()
 from /usr/lib64/hugin/libhuginbase.so.0.0
  No symbol table info available.
  #5  0x7f100b967c0e in HuginBase::NonaFileOutputStitcher::runStitcher() () 
from /usr/lib64/hugin/libhuginbase.so.0.0
  No symbol table info available.
  #6  0x00404d27 in main ()
  No symbol table info available.

  I'll rebuild and try again with unstripped 

[Hugin-devs] [Bug 1467678] [NEW] nona segfaults with PNG and TIFF output

2015-06-22 Thread Bruno Postle
Public bug reported:

System: fedora f22 x86_64
hugin 2015.0.0 rc1 c48252eb571f
libtiff-4.0.3
libpng-1.6.16
libjpeg-turbo-1.4.0
vigra-1.10.0

I'm getting a segfault from nona with PNG and TIFF output, JPEG is fine.

This is a simple single image project with JPEG input:

  nona -i 0 -m TIFF  -o junk project.pto
  Segmentation fault (core dumped)

Result is the same with or without -m parameter and with multiple photo 
projects.
OMP_NUM_THREADS=1 doesn't help. I don't have a suitable GPU so I can't test 
that.

Thread 1 (Thread 0x7f100c213900 (LWP 3761)):
#0  0x7f100bbabbc8 in void vigra::detail::exportImagevigra::Diff2D, 
vigra::MultiImageVectorMaskAccessor4vigra::ConstBasicImageIteratorvigra::RGBValueunsigned
 char, 0u, 1u, 2u, vigra::RGBValueunsigned char, 0u, 1u, 2u**, 
vigra::RGBAccessorvigra::RGBValueunsigned char, 0u, 1u, 2u , 
vigra::ConstBasicImageIteratorunsigned char, unsigned char**, 
vigra::StandardConstValueAccessorunsigned char  (vigra::Diff2D, 
vigra::Diff2D, 
vigra::MultiImageVectorMaskAccessor4vigra::ConstBasicImageIteratorvigra::RGBValueunsigned
 char, 0u, 1u, 2u, vigra::RGBValueunsigned char, 0u, 1u, 2u**, 
vigra::RGBAccessorvigra::RGBValueunsigned char, 0u, 1u, 2u , 
vigra::ConstBasicImageIteratorunsigned char, unsigned char**, 
vigra::StandardConstValueAccessorunsigned char , vigra::ImageExportInfo 
const, vigra::VigraFalseType)
() from /usr/lib64/hugin/libhuginbase.so.0.0
No symbol table info available.
#1  0x7f100bb9760a in void 
vigra::exportImageAlphavigra::ConstBasicImageIteratorvigra::RGBValueunsigned 
char, 0u, 1u, 2u, vigra::RGBValueunsigned char, 0u, 1u, 2u**, 
vigra::RGBAccessorvigra::RGBValueunsigned char, 0u, 1u, 2u , 
vigra::ConstBasicImageIteratorunsigned char, unsigned char**, 
vigra::StandardConstValueAccessorunsigned char 
(vigra::triplevigra::ConstBasicImageIteratorvigra::RGBValueunsigned char, 
0u, 1u, 2u, vigra::RGBValueunsigned char, 0u, 1u, 2u**, 
vigra::ConstBasicImageIteratorvigra::RGBValueunsigned char, 0u, 1u, 2u, 
vigra::RGBValueunsigned char, 0u, 1u, 2u**, 
vigra::RGBAccessorvigra::RGBValueunsigned char, 0u, 1u, 2u  , 
std::pairvigra::ConstBasicImageIteratorunsigned char, unsigned char**, 
vigra::StandardConstValueAccessorunsigned char , vigra::ImageExportInfo 
const, vigra::VigraFalseType) [clone .isra.915] [clone .constprop.1312] () 
from /usr/lib64/hugin/libhuginbase.so.0.0
No symbol table info available.
#2  0x7f100bbbe152 in 
HuginBase::Nona::WeightedStitchervigra::BasicImagevigra::RGBValueunsigned 
char, 0u, 1u, 2u, std::allocatorvigra::RGBValueunsigned char, 0u, 1u, 2u  
, vigra::BasicImageunsigned char, std::allocatorunsigned char  
::stitch(HuginBase::PanoramaOptions const, std::setunsigned int, 
std::lessunsigned int, std::allocatorunsigned int , std::string const, 
HuginBase::Nona::SingleImageRemappervigra::BasicImagevigra::RGBValueunsigned 
char, 0u, 1u, 2u, std::allocatorvigra::RGBValueunsigned char, 0u, 1u, 2u  
, vigra::BasicImageunsigned char, std::allocatorunsigned char  , 
std::mapstd::string, std::string, std::lessstd::string, 
std::allocatorstd::pairstd::string const, std::string   const) () from 
/usr/lib64/hugin/libhuginbase.so.0.0
No symbol table info available.
#3  0x7f100bb981e9 in 
HuginBase::Nona::stitchPanoRGB_8_16(HuginBase::PanoramaData const, 
HuginBase::PanoramaOptions const, AppBase::ProgressDisplay*, std::string 
const, std::setunsigned int, std::lessunsigned int, std::allocatorunsigned 
int  const, char const*, std::mapstd::string, std::string, 
std::lessstd::string, std::allocatorstd::pairstd::string const, 
std::string   const) ()
   from /usr/lib64/hugin/libhuginbase.so.0.0
No symbol table info available.
#4  0x7f100bcd2c9a in 
HuginBase::Nona::stitchPanorama(HuginBase::PanoramaData const, 
HuginBase::PanoramaOptions const, AppBase::ProgressDisplay*, std::string 
const, std::setunsigned int, std::lessunsigned int, std::allocatorunsigned 
int  const, std::mapstd::string, std::string, std::lessstd::string, 
std::allocatorstd::pairstd::string const, std::string   const) ()
   from /usr/lib64/hugin/libhuginbase.so.0.0
No symbol table info available.
#5  0x7f100b967c0e in HuginBase::NonaFileOutputStitcher::runStitcher() () 
from /usr/lib64/hugin/libhuginbase.so.0.0
No symbol table info available.
#6  0x00404d27 in main ()
No symbol table info available.

I'll rebuild and try again with unstripped binaries.

** 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/1467678

Title:
  nona segfaults with PNG and TIFF output

Status in Hugin - Panorama Tools GUI:
  New

Bug description:
  System: fedora f22 x86_64
  hugin 2015.0.0 rc1 c48252eb571f
  libtiff-4.0.3
  libpng-1.6.16
  libjpeg-turbo-1.4.0
  vigra-1.10.0

  I'm getting a segfault from nona with PNG and TIFF output, JPEG is
  fine.

  This is a simple single image project with 

[Hugin-devs] [Bug 1467678] Re: nona segfaults with PNG and TIFF output

2015-06-22 Thread Bruno Postle
Here's a better stacktrace:

Core was generated by `nona -i 0 -m TIFF -o junk DSC_0251 - DSC_0254.pto'.
Program terminated with signal SIGSEGV, Segmentation fault.

Thread 1 (Thread 0x7ff2da3e5900 (LWP 11921)):
#0  operator() (v=@0x0: error reading variable, this=synthetic pointer) at 
/usr/include/vigra/inspectimage.hxx:1043
No locals.
#1  
inspectLinevigra::IteratorAdaptorvigra::Diff2DConstRowIteratorPolicyvigra::Diff2D
 , 
vigra::VectorElementAccessorvigra::MultiImageVectorMaskAccessor4vigra::ConstBasicImageIteratorvigra::RGBValueunsigned
 char, vigra::RGBValueunsigned char**, 
vigra::RGBAccessorvigra::RGBValueunsigned char , 
vigra::ConstBasicImageIteratorunsigned char, unsigned char**, 
vigra::StandardConstValueAccessorunsigned char  , 
vigra::FindMinMaxunsigned char  (f=synthetic pointer, send=..., s=..., 
src=...) at /usr/include/vigra/inspectimage.hxx:71
No locals.
#2  operator()vigra::FindMinMaxunsigned char  (f=synthetic pointer, 
this=optimized out) at /usr/include/vigra/inspectimage.hxx:225
t = {x = optimized out, y = 0}
w = 8536
#3  extra_passes_selectvigra::inspectImage_bindervigra::Diff2D, 
vigra::VectorElementAccessorvigra::MultiImageVectorMaskAccessor4vigra::ConstBasicImageIteratorvigra::RGBValueunsigned
 char, vigra::RGBValueunsigned char**, 
vigra::RGBAccessorvigra::RGBValueunsigned char , 
vigra::ConstBasicImageIteratorunsigned char, unsigned char**, 
vigra::StandardConstValueAccessorunsigned char   , 
vigra::FindMinMaxunsigned char  (f=synthetic pointer, g=...) at 
/usr/include/vigra/inspector_passes.hxx:71
No locals.
#4  inspectImagevigra::Diff2D, 
vigra::VectorElementAccessorvigra::MultiImageVectorMaskAccessor4vigra::ConstBasicImageIteratorvigra::RGBValueunsigned
 char, vigra::RGBValueunsigned char**, 
vigra::RGBAccessorvigra::RGBValueunsigned char , 
vigra::ConstBasicImageIteratorunsigned char, unsigned char**, 
vigra::StandardConstValueAccessorunsigned char  , 
vigra::FindMinMaxunsigned char  (
f=synthetic pointer, a=..., lowerright=..., upperleft=...) at 
/usr/include/vigra/inspectimage.hxx:236
No locals.
#5  find_value_rangevigra::Diff2D, 
vigra::MultiImageVectorMaskAccessor4vigra::ConstBasicImageIteratorvigra::RGBValueunsigned
 char, vigra::RGBValueunsigned char**, 
vigra::RGBAccessorvigra::RGBValueunsigned char , 
vigra::ConstBasicImageIteratorunsigned char, unsigned char**, 
vigra::StandardConstValueAccessorunsigned char   (lower_right=..., 
upper_left=..., accessor=...)
at /usr/include/vigra/impexbase.hxx:164
i = 0
extrema = {min = 255 '\377', max = 0 '\000', count = 0}
#6  find_source_value_rangevigra::Diff2D, 
vigra::MultiImageVectorMaskAccessor4vigra::ConstBasicImageIteratorvigra::RGBValueunsigned
 char, vigra::RGBValueunsigned char**, 
vigra::RGBAccessorvigra::RGBValueunsigned char , 
vigra::ConstBasicImageIteratorunsigned char, unsigned char**, 
vigra::StandardConstValueAccessorunsigned char   (lower_right=..., 
upper_left=..., export_info=..., accessor=...)
at /usr/include/vigra/impexbase.hxx:185
range = optimized out
#7  vigra::detail::exportImagevigra::Diff2D, 
vigra::MultiImageVectorMaskAccessor4vigra::ConstBasicImageIteratorvigra::RGBValueunsigned
 char, 0u, 1u, 2u, vigra::RGBValueunsigned char, 0u, 1u, 2u**, 
vigra::RGBAccessorvigra::RGBValueunsigned char, 0u, 1u, 2u , 
vigra::ConstBasicImageIteratorunsigned char, unsigned char**, 
vigra::StandardConstValueAccessorunsigned char   (image_upper_left=..., 
image_lower_right=..., image_accessor=..., export_info=...) at 
/usr/include/vigra/impex.hxx:550
encoder = std::unique_ptrvigra::Encoder containing 0x22f6330
pixel_type = UINT8
downcast = false
type = vigra::UNSIGNED_INT_8
image_source_range = optimized out
destination_range = optimized out
#8  0x7ff2d9d675da in exportImagevigra::Diff2D, 
vigra::MultiImageVectorMaskAccessor4vigra::ConstBasicImageIteratorvigra::RGBValueunsigned
 char, vigra::RGBValueunsigned char**, 
vigra::RGBAccessorvigra::RGBValueunsigned char , 
vigra::ConstBasicImageIteratorunsigned char, unsigned char**, 
vigra::StandardConstValueAccessorunsigned char   (export_info=..., 
image_accessor=..., image_lower_right=..., 
image_upper_left=...) at /usr/include/vigra/impex.hxx:972
No locals.
#9  
vigra::exportImageAlphavigra::ConstBasicImageIteratorvigra::RGBValueunsigned 
char, 0u, 1u, 2u, vigra::RGBValueunsigned char, 0u, 1u, 2u**, 
vigra::RGBAccessorvigra::RGBValueunsigned char, 0u, 1u, 2u , 
vigra::ConstBasicImageIteratorunsigned char, unsigned char**, 
vigra::StandardConstValueAccessorunsigned char  (info=..., image=..., 
alpha=...)
at /usr/src/debug/hugin-2015.0.0/src/hugin_base/vigra_ext/impexalpha.hxx:394
No locals.
#10 0x7ff2d9d8e122 in 
exportImageAlphavigra::ConstBasicImageIteratorvigra::RGBValueunsigned char, 
vigra::RGBValueunsigned char**, vigra::RGBAccessorvigra::RGBValueunsigned 
char , vigra::ConstBasicImageIteratorunsigned char, unsigned char**, 

[Hugin-devs] [Bug 1320750] Re: Split file filter (*.pto, *.ptp, *.pts, *.oto) into several

2014-05-21 Thread Bruno Postle
.pts files are ptgui projects and .ptp files are for ptassembler.

Having two options as suggested should be fine:
*.pto (default)
* (all files)

The .oto extension was used for a while for output from autopano-sift to
distinguish it from optimised .pto projects. We don't need to care about
this anymore.

Though I think being able to start a project in ptgui or ptassembler and
switch to Hugin (and back again) is a valid use case. There are some
incompatibilities, particularly with circular cropping, but this doesn't
seem to bother people.

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

Title:
  Split file filter (*.pto, *.ptp, *.pts, *.oto) into several

Status in Hugin - Panorama Tools GUI:
  New

Bug description:
  *.pts file extension is used by Photivo (a RAW convertor) for its
  settings files. Hence I often have a lot of *.pts and *.pto files in
  one directory. It would be much easier to find Hugin panoramas if I
  could choose only *.pto files in the file filter in the open dialog.
  So I suggest to provide separate filters for these extensions instead
  of one filter.

To manage notifications about this bug go to:
https://bugs.launchpad.net/hugin/+bug/1320750/+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 1302564] Re: Jpeg files created with the panorama tool are correctly read and displayed by digikam but are wrong and are not readable by other softwares

2014-04-07 Thread Bruno Postle
*** This bug is a duplicate of bug 798952 ***
https://bugs.launchpad.net/bugs/798952

This is the 'arithmetic coding' bug, caused by your distribution
switching to libjeg-turbo.

Your distribution needs to apply a one-line patch to enblend or upgrade
to enblend 4.1 (which is more than a year old), see enblend bug #798952

** This bug has been marked a duplicate of bug 798952
   vigra_impex bug creates 'arithmetic coded' JPEG output

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

Title:
  Jpeg files created with the panorama tool are correctly read and
  displayed by digikam but are wrong and are not readable by other
  softwares

Status in Hugin - Panorama Tools GUI:
  New

Bug description:
  When creating panorama, I get nice files (.jpg) that I can display and 
manipulate with Digikam. However, this files seems to have a problem, and they 
can not be read outside Digikam. I tried to send them to other users, and they 
can not read them etheir.
  It seems that gnview can read them, but not Firefox, neither most of windows 
programs. Ubuntu can not create miniatures, and the default Ubuntu image 
display software can not open them either. Something seems to be wrong in the 
file format.

  Reproducible: Always 
  Steps to Reproduce: 1. Create a panorama 2. Save it
  I'm using the latest stable Hugin release, under Ubuntu 13.10.
  See the attached jpg file as an example.

To manage notifications about this bug go to:
https://bugs.launchpad.net/hugin/+bug/1302564/+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 1301922] Re: Fast panorama editor very cumbersome to use

2014-04-07 Thread Bruno Postle
Hi, thanks for your comments, Hugin is still a work in progress and not
perfect.

What would be really useful would be mockup images of how you see a
better layout. This doesn't need to be a lot of work, either rough
sketches or rearranged screenshots might be enough to start a productive
discussion.

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

Title:
  Fast panorama editor very cumbersome to use

Status in Hugin - Panorama Tools GUI:
  New

Bug description:
  I want to suggest a few changes to the Fast Panorama Editor's
  interface which will vastly improve usability and shorten time spent
  working in it. Some parts of Hugin today in 2014 look like they've
  been designed either many years ago and bits and pieces were kept
  being added on without much concern for the overall appearance, or
  like it was designed to run on a small-screen phone. Luckily this can
  all be quickly fixed without much coding, just rearranging existing
  things.

  Currently there are six tabs in the Fast Panorama Editor, and clicking 
through them is a waste of time. Let's fix this:
  Assistant: input image control (projection, focal, sensor scale multiplier)
  Preview: a bunch of preview settings.
  Layout: it's a whole tab when in fact it is exactly one slider. A whole tab 
for a slider!
  Projection: output image control (projection, FOV, guides).
  Move/Drag: synonyms in the tab's name, y/p/r, again guides, 
center/fit/straighten.
  Crop: manual, auto, again guides.

  AT THE VERY LEAST let us move the images from the same tab we can
  change projection and crop from!

  To properly fix this, delete the tabs, they're a bad idea, they waste
  screen space like crazy, and merge things.

  Unified Fast Panorama Editor (UFPE).
  Consists of three main elements: the image control panels (two of them, one 
for input, one for output), the preview, and the preview controls.

  The first element, input/output image controls. Two panels (frames? not sure 
of the nomenclature in QT) at the top or on the left of the UFPE (depends on 
your screen aspect ratio, let them float so the user can choose), keep things 
small, don't waste space.
  First panel is your source image panel:
[+] to load images (no need for a 100 pixel long button!), [-] to remove 
currently selected image (click on it on the preview to select it).
Source image projection selector combobox.
Source image focal inputbox.
Source image sensor size multiplier inputbox.
  Second panel is your output image panel:
Projection selector combobox.
Projection parameters if any are needed (sliders for e.g. Panini)
[Straighten] button.
Yaw/pitch/roll numerical inputboxes of currently selected image or whole 
pano if none selected.
Crop sub-panel
  [Fit inside] auto-crop button (i.e. no black edges).
  [Fit outside] auto-crop button (i.e. with black edges).
  Crop numerical inputboxes.

  Second element, the main panorama preview. Click on an image to select
  it. Click+drag to... drag it. Right-click for a context menu if
  needed. ZOOM IN/OUT USING THE MOUSE; using the sliders as is currently
  needed is highly inefficient :] Add [+][-] buttons

  Third element, at the bottom of the window, is the preview control:
  Exposure, photometrics, show CPs, identify, blabla, guides, grid, scale.

  Everything on one screen, everything fits even on 1024x768, panels can
  be detached and floated. Less than a day's work for someone familiar
  with that window, because there is not much code to be written, just a
  bunch of things to be moved and a whole bunch of code to delete.

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


Re: [Hugin-devs] [Hugin-bug-hunters] [Bug 1271563] Re: Please provide an AppData file

2014-01-30 Thread Bruno Postle
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Thu 30-Jan-2014 at 22:08 -, tduell wrote:
Do you mean it is OK to install to $DATADIR/appdata whatever $PREFIX?
It now looks to me like I should be using the fixed path
/usr/share/appdata .

The only advantage of installing to /usr/local is that you can 
delete this folder and get back to a clean system.  If we are 
installing some stuff to /usr and other stuff to /usr/local then we 
are just making a mess - on a Linux distribution all files in /usr 
are typically controlled by the package manager.

Also it should be possible to do an install as a normal user to a 
private folder (e.g. when building rpm packages), this will fail if 
we try to create files in /usr/share.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.6 (GNU/Linux)

iD8DBQFS6tXJFqOhwCjyCLoRAgHqAJ9iktrf7Y26vHzpi73TSk0MdwQ5/QCdGPiE
ecMr+56UuDZiXeEOd09hbng=
=GwZQ
-END PGP SIGNATURE-

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

Title:
  Please provide an AppData file

Status in Hugin - Panorama Tools GUI:
  Confirmed

Bug description:
  Please add a AppData file for Hugin, else it looks really bad in the
  GNOME Software Center. See
  http://people.freedesktop.org/~hughsient/appdata/ for details; thanks!

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


Re: [Hugin-devs] [Hugin-bug-hunters] [Bug 1271563] Re: Please provide an AppData file

2014-01-30 Thread Bruno Postle
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Thu 30-Jan-2014 at 23:11 -, tduell wrote:
 None of that makes it any clearer to me as to what we should be doing.
 Sorry, it's probably just the way my mind works!

Basically, if the user wants to install everything in /usr/local or 
/opt/tuesday then that is where we put it, including .desktop files 
and appdata.

The appdata stuff only makes sense in the context of an package like 
an rpm, so it will all end up in /usr anyway.

- -- 
Bruno
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.6 (GNU/Linux)

iD8DBQFS6uUAFqOhwCjyCLoRAjaeAKCo19C3kL22T2aFXMOghgyOALL/UACfZHw/
DPB3KQmHKV48Od9z5t1KZ1g=
=X4Oo
-END PGP SIGNATURE-

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

Title:
  Please provide an AppData file

Status in Hugin - Panorama Tools GUI:
  Confirmed

Bug description:
  Please add a AppData file for Hugin, else it looks really bad in the
  GNOME Software Center. See
  http://people.freedesktop.org/~hughsient/appdata/ for details; thanks!

To manage notifications about this bug go to:
https://bugs.launchpad.net/hugin/+bug/1271563/+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 1271563] Re: Please provide an AppData file

2014-01-22 Thread Bruno Postle
Agreed, an AppData file would be a good thing to have.

Is a separate file required for each of the GUI tools? The Hugin package
ships three related GUI Applications.

** Changed in: hugin
   Status: New = Confirmed

** Changed in: hugin
   Importance: Undecided = Medium

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

Title:
  Please provide an AppData file

Status in Hugin - Panorama Tools GUI:
  Confirmed

Bug description:
  Please add a AppData file for Hugin, else it looks really bad in the
  GNOME Software Center. See
  http://people.freedesktop.org/~hughsient/appdata/ for details; thanks!

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


Re: [Hugin-devs] [Bug 1267806] Re: Panorama render artifacts in some SW with Hugin 2013

2014-01-13 Thread Bruno Postle
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Mon 13-Jan-2014 at 13:09 -, Andrew Travneff wrote:
Sure, it's here (280MB), unmodified:  http://www.ex.ua/538083568271

I'm still downloading the PNG file, but I noticed that it is 
33352x4696 pixels.  This is big but it should be fine with PNG.  The 
Vigra library used by Hugin/enblend has a hard limit of 2 
gigapixels, and different TIFF libraries have a 2 or 4 gigabyte 
filesize limit, but you are nowhere near this.

Is it possible that your image viewers only support a 32768 (2^15) 
pixel maximum dimension?  This would explain the artefacts in the 
right hand side of the image.

- -- 
Bruno
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.6 (GNU/Linux)

iD8DBQFS1AE9FqOhwCjyCLoRArFhAJ9szehSX7qgJtsJlZ50O9UxwAXTQQCfVCP0
2t4s/v3QSewODVzU5w7KTfA=
=2+hd
-END PGP SIGNATURE-

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

Title:
  Panorama render artifacts in some SW with Hugin 2013

Status in Hugin - Panorama Tools GUI:
  New

Bug description:
  Duplicating from questions section (#241262)

  I've used Hugin 2012 for several months and it was just great.
  After update to version 2013 there is some corruption in the final panorama 
and it isn't visible in all viewers (may be related to some other part, not 
Hugin).

  Example is attached. Cropped and converted from PNG to JPEG, just to show the 
pattern.
  TIFF output has the same issue.

  I use Fedora x64 and such a broken images are displayed fine (no stripes, no 
problems at all) in KolourPaint or Feh, for example.
  On the other hand, Viewnior and ImageMagick show the stripes and Firefox just 
refuses to load the image with error like the image cannot be displayed 
because it contains errors.

  The interesting thing is that image scaled down with ImageMagick
  doesn't have stripes if scaling coefficient is below ~0.95-0.96.

  Versions of the related packages:
  hugin-2013.0.0-5.fc20.x86_64
  enblend-4.1.2-1.fc20.x86_64

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


Re: [Hugin-devs] [Bug 1267806] Re: Panorama render artifacts in some SW with Hugin 2013

2014-01-13 Thread Bruno Postle
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Testing on fedora f20: I can create a 33000 pixel wide PNG image in 
GIMP, but it won't display in 'eog':

Gdk:ERROR:gdkcairo.c:193:gdk_cairo_surface_paint_pixbuf: assertion 
   failed: (cairo_image_surface_get_format (surface) == CAIRO_FORMAT_RGB24 
   || cairo_image_surface_get_format (surface) == CAIRO_FORMAT_ARGB32)

A 32000 wide image displays fine, so I assume this is a limitation 
of gnome3/cairo/gtk3/xorg, not a Hugin/enblend bug.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.6 (GNU/Linux)

iD8DBQFS1A0xFqOhwCjyCLoRAma8AJ9kNrq6VcCZuOrnH/sarhsQBE0WeACgpL5U
suBdYjuokf/ZVO6MR7Yeo9E=
=WeC5
-END PGP SIGNATURE-

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

Title:
  Panorama render artifacts in some SW with Hugin 2013

Status in Hugin - Panorama Tools GUI:
  New

Bug description:
  Duplicating from questions section (#241262)

  I've used Hugin 2012 for several months and it was just great.
  After update to version 2013 there is some corruption in the final panorama 
and it isn't visible in all viewers (may be related to some other part, not 
Hugin).

  Example is attached. Cropped and converted from PNG to JPEG, just to show the 
pattern.
  TIFF output has the same issue.

  I use Fedora x64 and such a broken images are displayed fine (no stripes, no 
problems at all) in KolourPaint or Feh, for example.
  On the other hand, Viewnior and ImageMagick show the stripes and Firefox just 
refuses to load the image with error like the image cannot be displayed 
because it contains errors.

  The interesting thing is that image scaled down with ImageMagick
  doesn't have stripes if scaling coefficient is below ~0.95-0.96.

  Versions of the related packages:
  hugin-2013.0.0-5.fc20.x86_64
  enblend-4.1.2-1.fc20.x86_64

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


Re: [Hugin-devs] [Bug 1267806] [NEW] Panorama render artifacts in some SW with Hugin 2013

2014-01-11 Thread Bruno Postle
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Fri 10-Jan-2014 at 11:39 -, Andrew Travneff wrote:

 I use Fedora x64 and such a broken images are displayed fine (no 
 stripes, no problems at all) in KolourPaint or Feh, for example.
 
 On the other hand, Viewnior and ImageMagick show the stripes and 
 Firefox just refuses to load the image with error like the image 
 cannot be displayed because it contains errors.

I don't think anything like this has been reported before, can you 
upload one of the corrupted TIFF/PNG files somewhere?

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.6 (GNU/Linux)

iD8DBQFS0b58FqOhwCjyCLoRAj1mAJ9dRwtUAYQWb2CMUiQPcq1+5i8YigCff7Mq
iqqS36Qr5kz7oJLque1AOJk=
=tqmA
-END PGP SIGNATURE-

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

Title:
  Panorama render artifacts in some SW with Hugin 2013

Status in Hugin - Panorama Tools GUI:
  New

Bug description:
  Duplicating from questions section (#241262)

  I've used Hugin 2012 for several months and it was just great.
  After update to version 2013 there is some corruption in the final panorama 
and it isn't visible in all viewers (may be related to some other part, not 
Hugin).

  Example is attached. Cropped and converted from PNG to JPEG, just to show the 
pattern.
  TIFF output has the same issue.

  I use Fedora x64 and such a broken images are displayed fine (no stripes, no 
problems at all) in KolourPaint or Feh, for example.
  On the other hand, Viewnior and ImageMagick show the stripes and Firefox just 
refuses to load the image with error like the image cannot be displayed 
because it contains errors.

  The interesting thing is that image scaled down with ImageMagick
  doesn't have stripes if scaling coefficient is below ~0.95-0.96.

  Versions of the related packages:
  hugin-2013.0.0-5.fc20.x86_64
  enblend-4.1.2-1.fc20.x86_64

To manage notifications about this bug go to:
https://bugs.launchpad.net/hugin/+bug/1267806/+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 1261921] [NEW] minor autobuild issues

2013-12-17 Thread Bruno Postle
Public bug reported:

I'm building the default mercurial branch and noticed a couple of minor
problems with the autotools build:

enblend-enblend.o fails because there is no dependency on signature.h,
so I get this error:

  enblend.cc:69:23: fatal error: signature.h: No such file or directory

The workaround is to:

  cd src; make signature.h

Next I get:

  make[1]: *** No rule to make target `layer_selection/liblayersel.a',
needed by `enblend'.  Stop.

So I have to do this:

  cd src/layer_selection; make liblayersel.a

After that it seems ok.

** Affects: enblend
 Importance: Undecided
 Status: New

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

Title:
  minor autobuild issues

Status in Enblend:
  New

Bug description:
  I'm building the default mercurial branch and noticed a couple of
  minor problems with the autotools build:

  enblend-enblend.o fails because there is no dependency on signature.h,
  so I get this error:

enblend.cc:69:23: fatal error: signature.h: No such file or
  directory

  The workaround is to:

cd src; make signature.h

  Next I get:

make[1]: *** No rule to make target `layer_selection/liblayersel.a',
  needed by `enblend'.  Stop.

  So I have to do this:

cd src/layer_selection; make liblayersel.a

  After that it seems ok.

To manage notifications about this bug go to:
https://bugs.launchpad.net/enblend/+bug/1261921/+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 1247418] Re: Website lacks 2013.0 update

2013-11-03 Thread Bruno Postle
Should be fixed now, it was broken because the website was updating from
the wrong mercurial branch.

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

Title:
  Website lacks 2013.0 update

Status in Hugin - Panorama Tools GUI:
  Fix Released

Bug description:
  The website makes no mention that Hugin 2013.0 has been released.

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


Re: [Hugin-devs] [Bug 1239609] [NEW] Allow easy entry of focal length and hfov

2013-10-14 Thread Bruno Postle
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Mon 14-Oct-2013 at 10:30 -, Christopher Allen wrote:

When the user knows the focal lengh and horizontal field of view (v),
Hugin should either compute the crop factor or, if it is not otherwise
needed, simply ignore it.

Consider cylindrical panorama camera images, which have an arbitrary
hfov unrelated to the lens and focal length, and for which 'crop factor'
is usually not a meaningful piece of information.  At present,
attempting to import such images is frustrating because when you enter
the hfov hugin resets the focal length (based on irrelevant default crop
factor of 1.0) and vice versa.  Instead, the crop factor should be
computed automatically (if it is needed at all).

Hugin should do this calculation, however this is just a convenience 
for photographers who are more familiar with concepts like focal 
length - The only number that is actually used in the stitching 
process is the horizontal field of view (v) parameter.

You can set the crop factor to anything you like so long as the 'v' 
parameter is correct.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.6 (GNU/Linux)

iD8DBQFSXGgIFqOhwCjyCLoRAqEIAKDSDBrSh9Dd50w1fIcQmgXNkTcQ4gCgyqiy
55PGHUlIeNokd0Ansdx382U=
=z2Gn
-END PGP SIGNATURE-

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

Title:
  Allow easy entry of focal length and hfov

Status in Hugin - Panorama Tools GUI:
  New

Bug description:
  When the user knows the focal lengh and horizontal field of view (v),
  Hugin should either compute the crop factor or, if it is not otherwise
  needed, simply ignore it.

  Consider cylindrical panorama camera images, which have an arbitrary
  hfov unrelated to the lens and focal length, and for which 'crop
  factor' is usually not a meaningful piece of information.  At present,
  attempting to import such images is frustrating because when you enter
  the hfov hugin resets the focal length (based on irrelevant default
  crop factor of 1.0) and vice versa.  Instead, the crop factor should
  be computed automatically (if it is needed at all).

To manage notifications about this bug go to:
https://bugs.launchpad.net/hugin/+bug/1239609/+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 1169204] Re: /tmp/buildpkgs/vigra/vigra-1.9.0/src/impex/codecmanager.cxx:234

2013-07-17 Thread Bruno Postle
Hi Georg, unfortunately vigra is mostly headers, the dynamically linked
library is just a small part of it.

So you need to install vigra then recompile enblend.

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

Title:
  /tmp/buildpkgs/vigra/vigra-1.9.0/src/impex/codecmanager.cxx:234

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

Bug description:
  ===
  ***  Panorama makefile generated by Hugin   ***
  ===
  System information
  ===
  Operating system: GNU/Linux
  Release: 3.2.29-smp
  Kernel version: #2 SMP Mon Sep 17 13:16:43 CDT 2012
  Machine: i686
  Disc usage
  Filesystem  Size  Used Avail Use% Mounted on
  /dev/sda114G  3.7G  9.6G  28% /
  /dev/sda387G   24G   59G  29% /sda3
  /dev/sda4   8.9G  149M  8.3G   2% /sda4
  tmpfs   490M 0  490M   0% /dev/shm
  Memory usage
   total   used   free sharedbuffers cached
  Mem:   978564413  0 13326
  -/+ buffers/cache:224753
  Swap: 1239  0   1239
  ===
  Output options
  ===
  Hugin Version: 2012.0.0.a94faa15c927
  Project file: /tmp/huginpto_0rZTPC
  Output prefix: IMG_0691-IMG_0692
  Projection: Rectilinear (0)
  Field of view: 50 x 39
  Canvas dimensions: 2230 x 1695
  Crop area: (40,23) - (2196,1627)
  Output exposure value: 8.45
  Selected outputs
  HDR merging
  * Merged and blended panorama
  ===
  Input images
  ===
  Number of images in project file: 2
  Number of active images: 2
  Image 0: /home/use/Desktop/IMG_0691.JPG
  Image 0: Size 3072x2304, Exposure: 10.14
  Image 1: /home/use/Desktop/IMG_0692.JPG
  Image 1: Size 3072x2304, Exposure: 6.76
  ===
  Testing programs
  ===
  Checking nona...[OK]
  Checking enblend...[OK]
  Checking enfuse...[OK]
  Checking hugin_hdrmerge...[OK]
  Checking exiftool...[OK]
  ===
  Stitching panorama
  ===
  nona  -r hdr -m EXR_m -o IMG_0691-IMG_0692_hdr_ -i 0 /tmp/huginpto_0rZTPC
  nona  -r hdr -m EXR_m -o IMG_0691-IMG_0692_hdr_ -i 1 /tmp/huginpto_0rZTPC
  hugin_hdrmerge -m avg -c -o IMG_0691-IMG_0692_stack_hdr_.exr -- 
IMG_0691-IMG_0692_hdr_.exr IMG_0691-IMG_0692_hdr_0001.exr
  /usr/bin/enblend  -f2156x1604+40+23 -o IMG_0691-IMG_0692_hdr.exr -- 
IMG_0691-IMG_0692_stack_hdr_.exr 
  terminate called after throwing an instance of 'vigra::PreconditionViolation'
what():  
  Precondition violation!
  did not find a matching file type.
  (/tmp/buildpkgs/vigra/vigra-1.9.0/src/impex/codecmanager.cxx:234)

  make: *** [IMG_0691-IMG_0692_hdr.exr] Aborted

To manage notifications about this bug go to:
https://bugs.launchpad.net/enblend/+bug/1169204/+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 1169204] Re: /tmp/buildpkgs/vigra/vigra-1.9.0/src/impex/codecmanager.cxx:234

2013-07-08 Thread Bruno Postle
Hi Georg, you are trying to blend EXR files into TIFF output, but your
enblend binary is compiled without EXR support:

 Supported image formats: BMP GIF HDR JPEG PNG PNM SUN TIFF VIFF
 Supported file extensions: bmp gif hdr jpeg jpg pbm pgm png pnm ppm ras tif 
 tiff xv

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

Title:
  /tmp/buildpkgs/vigra/vigra-1.9.0/src/impex/codecmanager.cxx:234

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

Bug description:
  ===
  ***  Panorama makefile generated by Hugin   ***
  ===
  System information
  ===
  Operating system: GNU/Linux
  Release: 3.2.29-smp
  Kernel version: #2 SMP Mon Sep 17 13:16:43 CDT 2012
  Machine: i686
  Disc usage
  Filesystem  Size  Used Avail Use% Mounted on
  /dev/sda114G  3.7G  9.6G  28% /
  /dev/sda387G   24G   59G  29% /sda3
  /dev/sda4   8.9G  149M  8.3G   2% /sda4
  tmpfs   490M 0  490M   0% /dev/shm
  Memory usage
   total   used   free sharedbuffers cached
  Mem:   978564413  0 13326
  -/+ buffers/cache:224753
  Swap: 1239  0   1239
  ===
  Output options
  ===
  Hugin Version: 2012.0.0.a94faa15c927
  Project file: /tmp/huginpto_0rZTPC
  Output prefix: IMG_0691-IMG_0692
  Projection: Rectilinear (0)
  Field of view: 50 x 39
  Canvas dimensions: 2230 x 1695
  Crop area: (40,23) - (2196,1627)
  Output exposure value: 8.45
  Selected outputs
  HDR merging
  * Merged and blended panorama
  ===
  Input images
  ===
  Number of images in project file: 2
  Number of active images: 2
  Image 0: /home/use/Desktop/IMG_0691.JPG
  Image 0: Size 3072x2304, Exposure: 10.14
  Image 1: /home/use/Desktop/IMG_0692.JPG
  Image 1: Size 3072x2304, Exposure: 6.76
  ===
  Testing programs
  ===
  Checking nona...[OK]
  Checking enblend...[OK]
  Checking enfuse...[OK]
  Checking hugin_hdrmerge...[OK]
  Checking exiftool...[OK]
  ===
  Stitching panorama
  ===
  nona  -r hdr -m EXR_m -o IMG_0691-IMG_0692_hdr_ -i 0 /tmp/huginpto_0rZTPC
  nona  -r hdr -m EXR_m -o IMG_0691-IMG_0692_hdr_ -i 1 /tmp/huginpto_0rZTPC
  hugin_hdrmerge -m avg -c -o IMG_0691-IMG_0692_stack_hdr_.exr -- 
IMG_0691-IMG_0692_hdr_.exr IMG_0691-IMG_0692_hdr_0001.exr
  /usr/bin/enblend  -f2156x1604+40+23 -o IMG_0691-IMG_0692_hdr.exr -- 
IMG_0691-IMG_0692_stack_hdr_.exr 
  terminate called after throwing an instance of 'vigra::PreconditionViolation'
what():  
  Precondition violation!
  did not find a matching file type.
  (/tmp/buildpkgs/vigra/vigra-1.9.0/src/impex/codecmanager.cxx:234)

  make: *** [IMG_0691-IMG_0692_hdr.exr] Aborted

To manage notifications about this bug go to:
https://bugs.launchpad.net/enblend/+bug/1169204/+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 1177077] Re: jpeg files cannot be opened by eye of gnome nor Xnview

2013-05-06 Thread Bruno Postle
This looks like the 'arithmetic coding' bug that was fixed in enblend:
Bug #798952

What version of enblend do you have installed (it may be called enblend-
enfuse on Ubuntu)?

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

Title:
  jpeg files cannot be opened by eye of gnome nor Xnview

Status in Hugin - Panorama Tools GUI:
  New

Bug description:
  Hi,

  I used Hugin a lot under windows. I now switched to Ubuntu.
  Unfortumately the jpeg are nor readable by eye of gnome and there is
  neither a  preview  in the folder view.

  Here is my system information:

  Betriebssystem: Linux 3.5.0-28-generic x86_64
  Architektur: 64 bit
  Freier Speicher:  788960 kiB

  Hugin
  Version: 2012.0.0.a94faa15c927
  Ressourcen-Pfad: /usr/share/hugin/xrc/
  Datenpfad: /usr/share/hugin/data/
  Pfad zur privaten lensfun-Datenbank: /home/georg/.local/share/lensfun

  Bibliotheken
  wxWidgets: 2.8.12.1
  libpano13: 2.9.18 
  Boost: 1.49.0
  Exiv2: 0.23.0

  I included a small panorama for demonstration.

  Greetings,

  Georg

To manage notifications about this bug go to:
https://bugs.launchpad.net/hugin/+bug/1177077/+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 1165912] [NEW] autoconf doesn't support arm 64

2013-04-07 Thread Bruno Postle
Public bug reported:

Another bug report from Fedora bugzilla...

Apparently enblend-enfuse needs to use autoconf-2.69 in order to support
building for the ARM 64 architecture:
https://bugzilla.redhat.com/show_bug.cgi?id=925312

** Affects: enblend
 Importance: Undecided
 Status: New

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

Title:
  autoconf doesn't support arm 64

Status in Enblend:
  New

Bug description:
  Another bug report from Fedora bugzilla...

  Apparently enblend-enfuse needs to use autoconf-2.69 in order to
  support building for the ARM 64 architecture:
  https://bugzilla.redhat.com/show_bug.cgi?id=925312

To manage notifications about this bug go to:
https://bugs.launchpad.net/enblend/+bug/1165912/+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 1155350] [NEW] build with texinfo 5.1

2013-03-14 Thread Bruno Postle
Public bug reported:

The downstream fedora enblend package is carrying this patch (by Rex
Dieter), he says it's upstreamable so here you go:

  fix pdf generation with recent texlive, set TEXINPUTS properly
(upstreamable)

** Affects: enblend
 Importance: Undecided
 Status: New

** Patch added: enblend-enfuse-4.1.1-TEXINPUTS.patch
   
https://bugs.launchpad.net/bugs/1155350/+attachment/3574670/+files/enblend-enfuse-4.1.1-TEXINPUTS.patch

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

Title:
  build with texinfo 5.1

Status in Enblend:
  New

Bug description:
  The downstream fedora enblend package is carrying this patch (by Rex
  Dieter), he says it's upstreamable so here you go:

fix pdf generation with recent texlive, set TEXINPUTS properly
  (upstreamable)

To manage notifications about this bug go to:
https://bugs.launchpad.net/enblend/+bug/1155350/+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 1052231] Re: info and man pages in mercurial

2012-09-20 Thread Bruno Postle
No, I create a tarball and use this to create a rpm package in a clean
mock chroot. Among other things this tests the full build from source,
tests the dist target, and verifies all the dependencies. These snapshot
packages get tested by people using the Hugin snapshots, so there are no
surprises when the final release goes into fedora.

I can run `make dist` in a different directory using vpath, but it will
still do a full build of the binaries even though they don't go in the
dist target, this seems unnecessary.

The version labelling in the tarball name is fine if that is how you
want to do it, the problem is that the tarball also includes a directory
with this name. i.e. I can download the 'enblend-enfuse-4.0.tar.gz' file
from sourceforge, but if I extract the files it creates a directory
called 'enblend-enfuse-4.0-753b534c819d' rather than the expected
'enblend-enfuse-4.0'.

If you plan to change this string to (e.g.) 'rc3', then the result will
be that the final 4.1 release tarball will contain a directory called
'enblend-4.1rc3' - Unless you change the string after the final release
candidate, but usual practice is that the final release tarball is byte-
for-byte identical to the final release candidate.

Hope this makes sense. I can cope with these things since I'm going to
package enblend whatever, but if the source behaves in a 'normal' way
then it vastly increases the chances of enblend getting into all the
Linux/BSD distributions promptly.

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

Title:
  info and man pages in mercurial

Status in Enblend:
  New

Bug description:
  Hi, a couple of minor issues with the enblend autotools setup, fixing
  these would make things easier for packagers:

  The mercurial repository contains generated files (enblend.1,
  enblend.info etc...), these get rebuilt locally, resulting in a
  conflict that needs to be resolved every time we pull from the
  sourceforge repository. Ideally the repository wouldn't contain these
  files, though it makes sense for the dist target to build the info and
  man pages and include them in the tarball.

  The dist target does a full build of the executables even though they
  are not included in the tarball, this means creating a tarball for
  packaging as rpm/deb takes twice as long as it needs to.

  The dist target creates a tarball with the mercurial revision in the
  filename, e.g. enblend-enfuse-4.1-1bcd3b5cb866.tar.gz, this is a bit
  unusual but ok for development snapshots. The problem is it also
  includes a directory called 'enblend-enfuse-4.1-1bcd3b5cb866' even
  when the tarball is renamed for a stable release. So when we are
  packaging enblend it is necessary to change the rules every time to
  account for this variable directory name.

To manage notifications about this bug go to:
https://bugs.launchpad.net/enblend/+bug/1052231/+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 1052231] [NEW] info and man pages in mercurial

2012-09-17 Thread Bruno Postle
Public bug reported:

Hi, a couple of minor issues with the enblend autotools setup, fixing
these would make things easier for packagers:

The mercurial repository contains generated files (enblend.1,
enblend.info etc...), these get rebuilt locally, resulting in a conflict
that needs to be resolved every time we pull from the sourceforge
repository. Ideally the repository wouldn't contain these files, though
it makes sense for the dist target to build the info and man pages and
include them in the tarball.

The dist target does a full build of the executables even though they
are not included in the tarball, this means creating a tarball for
packaging as rpm/deb takes twice as long as it needs to.

The dist target creates a tarball with the mercurial revision in the
filename, e.g. enblend-enfuse-4.1-1bcd3b5cb866.tar.gz, this is a bit
unusual but ok for development snapshots. The problem is it also
includes a directory called 'enblend-enfuse-4.1-1bcd3b5cb866' even when
the tarball is renamed for a stable release. So when we are packaging
enblend it is necessary to change the rules every time to account for
this variable directory name.

** Affects: enblend
 Importance: Undecided
 Status: New

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

Title:
  info and man pages in mercurial

Status in Enblend:
  New

Bug description:
  Hi, a couple of minor issues with the enblend autotools setup, fixing
  these would make things easier for packagers:

  The mercurial repository contains generated files (enblend.1,
  enblend.info etc...), these get rebuilt locally, resulting in a
  conflict that needs to be resolved every time we pull from the
  sourceforge repository. Ideally the repository wouldn't contain these
  files, though it makes sense for the dist target to build the info and
  man pages and include them in the tarball.

  The dist target does a full build of the executables even though they
  are not included in the tarball, this means creating a tarball for
  packaging as rpm/deb takes twice as long as it needs to.

  The dist target creates a tarball with the mercurial revision in the
  filename, e.g. enblend-enfuse-4.1-1bcd3b5cb866.tar.gz, this is a bit
  unusual but ok for development snapshots. The problem is it also
  includes a directory called 'enblend-enfuse-4.1-1bcd3b5cb866' even
  when the tarball is renamed for a stable release. So when we are
  packaging enblend it is necessary to change the rules every time to
  account for this variable directory name.

To manage notifications about this bug go to:
https://bugs.launchpad.net/enblend/+bug/1052231/+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 1049994] Re: Fast Preview Unsupported Panorama Format error

2012-09-16 Thread Bruno Postle
Thanks, applied in SVN r1349

Also you now have panotools svn access

** Changed in: panotools
   Status: New = Fix Committed

** Changed in: hugin
   Status: New = Fix Committed

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

Title:
  Fast Preview Unsupported Panorama Format error

Status in Hugin - Panorama Tools GUI:
  Fix Committed
Status in Panorama Tools:
  Fix Committed

Bug description:
  I get a pop-up error saying unsupported Panorama Format whenever I
  try to drag a panorama when the projection is set to Orthographic or
  Thoby Projection. Other projections are ok.

  The error is non-fatal, the drag succeeds and Hugin continues after
  dismissing the dialog box.

To manage notifications about this bug go to:
https://bugs.launchpad.net/hugin/+bug/1049994/+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 891912] Re: Inverse transformation from output projection to Thoby input image is wrong

2012-09-16 Thread Bruno Postle
Thanks applied to panotools SVN r1350

** Changed in: panotools
   Status: New = Fix Committed

** Changed in: hugin
   Status: Confirmed = Fix Committed

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

Title:
  Inverse transformation from output projection to Thoby input image is
  wrong

Status in Hugin - Panorama Tools GUI:
  Fix Committed
Status in Panorama Tools:
  Fix Committed

Bug description:
  pto attached that highlights the problem.

  email sent to hugin-ptx yesterday:

  ===
  Hi there!

  I'm experiencing a very weird behavior in hugin 2011.2.0 on a gentoo
  64 box. I have a 360 pano of 15 shots taken with a full frame fisheye
  10.5mm. There are so many shots because I am doing a clone photography
  experiment of the same subject several times in the pano.

  I've set up masks accordingly to include the subject in all relevant
  shots. masks do not overlap accross shots.

  For 2 of the shots, where the subject is roughly 180 degree from
  himself, enabling both pics at the same time with masks gives me a
  completely wrong masking result (both in hugin and as exported by nona
  on stitching).

  I have a taken a few screenshots showing the problem here:
  http://timotheegroleau.com/bugs/2016_hugin_mask/

  note the incorrect render when both pics are activated simultaneously.

  Has anyone experienced this before? How can I troubleshoot and fix
  this?

  Thanks in advance!
  Tim
  ===

  reply from Bruno Postle
  ===
  Yes we have seen and fixed similar bugs with masks and fisheye
  photos before.  The workaround is to just edit the mask and move
  some nodes, the problem should go away.

  ..but before you do that please save the .pto file and attach it to a
  bug report on launchpad: https://bugs.launchpad.net/hugin/+filebug
  ===

  
  I have tried to edit the masks to be as close as possible to the subjects 
outline, I can't get the problem to go away :(

To manage notifications about this bug go to:
https://bugs.launchpad.net/hugin/+bug/891912/+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 1023037] Re: Enblend fails to build with boost 1.50

2012-08-20 Thread Bruno Postle
I see this same problem on fedora f18 which has boost-1.50 (this is with
the fedora boost-devel, boost-system and boost-filesystem packages
installed amongst others):

   checking boost/filesystem.hpp usability... yes
   checking boost/filesystem.hpp presence... yes
   checking for boost/filesystem.hpp... yes
   configure: Boost filesystem header or library not found.  Using built-in 
support.

[snip]

   CXXFLAGS:   -pthread -I/usr/include/OpenEXR   -O2 -g 
-pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector 
--param=ssp-buffer-size=4  -m32 -march=i686 -mtune=atom -fasynchrono
us-unwind-tables --param inline-unit-growth=60 -O2 -DNDEBUG -Wall
   LDFLAGS:-Wl,-z,relro 
   LIBS:   -pthread -lIlmImf -lImath -lHalf -lIex 
-lIlmThread   -lvigraimpex -lxmi -llcms2 -ltiff -lpng -ljpeg -lz -lgsl 
-lgslcblas -lm 
   OPENGL_LIBS:-lGLEW -lGLU -lGL  -lm -lglut  -lSM -lICE 
-lXmu -lXi  -lGLU -lGL  -lm

..and later:

  g++-D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -I../include 
-I../src/layer_selection -pthread -I/usr/include/OpenEXR   -O2 -g -pipe -Wall 
-Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector 
--param=ssp-buffer-size=4  -m32 -march=i686 -mtune=atom 
-fasynchronous-unwind-tables --param inline-unit-growth=60 -O2 -DNDEBUG -Wall   
-Wl,-z,relro  -o enblend enblend-enblend.o enblend-gpu.o 
enblend-error_message.o enblend-filenameparse.o enblend-filespec.o 
enblend-self_test.o enblend-tiff_message.o layer_selection/liblayersel.a  
-lGLEW -lGLU -lGL  -lm -lglut  -lSM -lICE -lXmu -lXi  -lGLU -lGL  -lm  -pthread 
-lIlmImf -lImath -lHalf -lIex -lIlmThread   -lvigraimpex -lxmi -llcms2 -ltiff 
-lpng -ljpeg -lz -lgsl -lgslcblas -lm 
enblend-enblend.o: In function `__static_initialization_and_destruction_0':
  /usr/include/boost/system/error_code.hpp:214: undefined reference to 
`boost::system::generic_category()'
  /usr/include/boost/system/error_code.hpp:215: undefined reference to 
`boost::system::generic_category()'
  /usr/include/boost/system/error_code.hpp:216: undefined reference to 
`boost::system::system_category()'

I'll try again with --with-boost-filesystem, but this seems to be a
genuine bug.

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

Title:
  Enblend fails to build with boost 1.50

Status in Enblend:
  Triaged

Bug description:
  Building enblend fails with the following error:

  g++   -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -I../include -DVIGRA_STATIC_LIB 
-D_THREAD_SAFE -I/opt/local/include/OpenEXR--param inline-unit-growth=60 
-O2 -DNDEBUG -Wall   -L/opt/local/lib -o enblend enblend-enblend.o 
enblend-gpu.o enblend-error_message.o enblend-filenameparse.o 
enblend-filespec.o enblend-self_test.o enblend-tiff_message.o 
vigra_impex/libvigra_impex.a   -L/opt/local/lib -lIlmImf -lz -lImath -lHalf 
-lIex -lIlmThread -lpthread   -lxmi -llcms -ltiff -lpng -ljpeg -lz 
  Undefined symbols for architecture x86_64:
boost::system::generic_category(), referenced from:
global constructors keyed to commandin enblend-enblend.o
boost::system::system_category(), referenced from:
global constructors keyed to commandin enblend-enblend.o
  ld: symbol(s) not found for architecture x86_64
  collect2: ld returned 1 exit status
  make[4]: *** [enblend] Error 1

  I can build enblend successfully when I switch back to boost 1.49.

To manage notifications about this bug go to:
https://bugs.launchpad.net/enblend/+bug/1023037/+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 1023037] Re: Enblend fails to build with boost 1.50

2012-08-20 Thread Bruno Postle
Ok, it no builds with boost-1.50 using --with-boost-filesystem

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

Title:
  Enblend fails to build with boost 1.50

Status in Enblend:
  Triaged

Bug description:
  Building enblend fails with the following error:

  g++   -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -I../include -DVIGRA_STATIC_LIB 
-D_THREAD_SAFE -I/opt/local/include/OpenEXR--param inline-unit-growth=60 
-O2 -DNDEBUG -Wall   -L/opt/local/lib -o enblend enblend-enblend.o 
enblend-gpu.o enblend-error_message.o enblend-filenameparse.o 
enblend-filespec.o enblend-self_test.o enblend-tiff_message.o 
vigra_impex/libvigra_impex.a   -L/opt/local/lib -lIlmImf -lz -lImath -lHalf 
-lIex -lIlmThread -lpthread   -lxmi -llcms -ltiff -lpng -ljpeg -lz 
  Undefined symbols for architecture x86_64:
boost::system::generic_category(), referenced from:
global constructors keyed to commandin enblend-enblend.o
boost::system::system_category(), referenced from:
global constructors keyed to commandin enblend-enblend.o
  ld: symbol(s) not found for architecture x86_64
  collect2: ld returned 1 exit status
  make[4]: *** [enblend] Error 1

  I can build enblend successfully when I switch back to boost 1.49.

To manage notifications about this bug go to:
https://bugs.launchpad.net/enblend/+bug/1023037/+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 1039226] Re: Feature request: nona -o PNG_m or nona -o JPEG_m

2012-08-20 Thread Bruno Postle
** Project changed: panotools = hugin

** Changed in: hugin
   Importance: Undecided = Wishlist

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

Title:
  Feature request: nona -o PNG_m   or   nona -o JPEG_m

Status in Hugin - Panorama Tools GUI:
  New

Bug description:
  Very simply, PNG or JPG format is required for web and other consumers
  like 3D environment maps where TIFF is not supported.

  Is it difficult to support

  nona -o JPEG_m script.pto
  or
  nona -o PNG_m  script.pto

  for creating a series of JPEG or PNG images where

  nona -o TIFF_m script.pto

  is currently used?

To manage notifications about this bug go to:
https://bugs.launchpad.net/hugin/+bug/1039226/+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 685877] Re: Push VIGRA changes to the right place

2012-08-19 Thread Bruno Postle
Confirmed, I can now build an enblend snapshot against the standard
fedora vigra-1.8.0 package without problems. Thanks.

Regarding the lack of alpha masks in output, is this something that
needs a patch pushing to vigra upstream? Being able to feed the output
from enblend (or enfuse) as input for more blending is a valid use case.

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

Title:
  Push VIGRA changes to the right place

Status in Enblend:
  In Progress
Status in Hugin - Panorama Tools GUI:
  Confirmed
Status in “enblend-enfuse” package in Debian:
  Confirmed
Status in “hugin” package in Debian:
  Confirmed
Status in “enblend” package in Fedora:
  New

Bug description:
  Enblend embeds a modified version of the VIGRA 1.4 library. Can we
  push the necessary changes to VIGRA's upstream and use the system
  version rather than an embedded copy?

  Details: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=542258

To manage notifications about this bug go to:
https://bugs.launchpad.net/enblend/+bug/685877/+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 1026790] [NEW] calibrate_lens_gui segfault clicking on canvas

2012-07-19 Thread Bruno Postle
Public bug reported:

Launching calibrate_lens_gui and clicking on either the file list or the
photo canvas area crashes with a segfault. Other widgets are ok, and
everything is fine once one or more photos are loaded.

Seen with fedora 16 'gui_overhaul' branch and Ubuntu 12.04, reported by
Alexandre Prokoudine.

** 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/1026790

Title:
  calibrate_lens_gui segfault clicking on canvas

Status in Hugin - Panorama Tools GUI:
  New

Bug description:
  Launching calibrate_lens_gui and clicking on either the file list or
  the photo canvas area crashes with a segfault. Other widgets are ok,
  and everything is fine once one or more photos are loaded.

  Seen with fedora 16 'gui_overhaul' branch and Ubuntu 12.04, reported
  by Alexandre Prokoudine.

To manage notifications about this bug go to:
https://bugs.launchpad.net/hugin/+bug/1026790/+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 1014417] [NEW] gui_overhaul branch crash removing photo from project

2012-06-17 Thread Bruno Postle
Public bug reported:

In the gui_overhaul branch (I'm running 5855:35cde63105dc)

If I create a project with two photos and remove the second photo using
the right-click context menu Hugin segfaults. It doesn't crash if I
remove the first photo.

Similarly if I create a project with 60 photos I get a segfault removing
most of them.

(originally reported by Patrick Bregman
https://bugzilla.redhat.com/show_bug.cgi?id=832711 )

** Affects: hugin
 Importance: Medium
 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/1014417

Title:
  gui_overhaul branch crash removing photo from project

Status in Hugin - Panorama Tools GUI:
  New

Bug description:
  In the gui_overhaul branch (I'm running 5855:35cde63105dc)

  If I create a project with two photos and remove the second photo
  using the right-click context menu Hugin segfaults. It doesn't crash
  if I remove the first photo.

  Similarly if I create a project with 60 photos I get a segfault
  removing most of them.

  (originally reported by Patrick Bregman
  https://bugzilla.redhat.com/show_bug.cgi?id=832711 )

To manage notifications about this bug go to:
https://bugs.launchpad.net/hugin/+bug/1014417/+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 1002474] [NEW] api-max setting for python plugins is only activated for stable releases

2012-05-21 Thread Bruno Postle
Public bug reported:

The python plugins have an 'api-max' value to prevent older plugins
being run with future releases of Hugin.

However this restriction is only enforced for stable even-numbered
releases, i.e. The plugins shipped with 2011.4.0 are disabled, but they
are not disabled with 2011.3.0 and 2011.5.0 snapshots. See
src/hugin1/hugin/PluginItems.cpp line 142.

The problem is that since most people who are in a position to check
this compatibility are using snapshots, they will never notice that the
api-max value needs incrementing.

So either:

The api-max check needs to be removed altogether.

..or it should be automatically set to the current release number, since
we should only be shipping compatible plugins.

..or it should be enforced for snapshots too - Making it more likely
that it will get fixed when a developer notices that plugins are
missing.

** 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/1002474

Title:
  api-max setting for python plugins is only activated for stable
  releases

Status in Hugin - Panorama Tools GUI:
  New

Bug description:
  The python plugins have an 'api-max' value to prevent older plugins
  being run with future releases of Hugin.

  However this restriction is only enforced for stable even-numbered
  releases, i.e. The plugins shipped with 2011.4.0 are disabled, but
  they are not disabled with 2011.3.0 and 2011.5.0 snapshots. See
  src/hugin1/hugin/PluginItems.cpp line 142.

  The problem is that since most people who are in a position to check
  this compatibility are using snapshots, they will never notice that
  the api-max value needs incrementing.

  So either:

  The api-max check needs to be removed altogether.

  ..or it should be automatically set to the current release number,
  since we should only be shipping compatible plugins.

  ..or it should be enforced for snapshots too - Making it more likely
  that it will get fixed when a developer notices that plugins are
  missing.

To manage notifications about this bug go to:
https://bugs.launchpad.net/hugin/+bug/1002474/+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 696634] Re: Hugin should support the lensfun lens database

2012-03-08 Thread Bruno Postle
Hi Thomas, current 6916593231ee works with the compact LX3 camera.
Loading the lens using lensfun adds plausible lens distortion
parameters, but doesn't alter the field-of-view - Looking at the lensfun
patch, this is a limitation of the older lensfun I have here.

A minor thing: in the 'load lens from database' window, the values for
focal length and aperture are rounded to the nearest whole number, these
would both be better as focal length: 5.1mm, Aperture f/4.0 rather
than focal length: 5mm, Aperture f/4.

BTW it builds fine on fedora f15, f16, f17  f18, all with both i386 and
x86_64.

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

Title:
  Hugin should support the lensfun lens database

Status in Hugin - Panorama Tools GUI:
  Fix Committed

Bug description:
  lensfun is a database and library that allows applications to access
  and save lens correction settings: http://lensfun.berlios.de/

  lensfun was in part designed for Hugin as a replacement for the
  existing .ini lens saving system, it is mature and has been adopted by
  ufraw and rawstudio, it is about time that Hugin started using it.

To manage notifications about this bug go to:
https://bugs.launchpad.net/hugin/+bug/696634/+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 696634] Re: Hugin should support the lensfun lens database

2012-03-06 Thread Bruno Postle
Thanks, links, builds and runs on fedora f15.

f15 has an old version of lensfun (0.2.5), so this report is probably
not very useful:

I have a compact Panasonic Lumix LX3, which is in the database, the lens
entry looks like this:

makerLeica/maker
modelStandard/model
mountpanasonicLX3/mount
  ...

I can only get a search match in Hugin with the string 'standard',
unfortunately there are 86 lenses called 'standard' in the database, so
it isn't practical to select the right one.

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

Title:
  Hugin should support the lensfun lens database

Status in Hugin - Panorama Tools GUI:
  Fix Committed

Bug description:
  lensfun is a database and library that allows applications to access
  and save lens correction settings: http://lensfun.berlios.de/

  lensfun was in part designed for Hugin as a replacement for the
  existing .ini lens saving system, it is mature and has been adopted by
  ufraw and rawstudio, it is about time that Hugin started using it.

To manage notifications about this bug go to:
https://bugs.launchpad.net/hugin/+bug/696634/+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 940840] Re: Setting masks as inactive

2012-02-25 Thread Bruno Postle
** Tags added: gsoc

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

Title:
  Setting masks as inactive

Status in Hugin - Panorama Tools GUI:
  Triaged

Bug description:
  Feature request:
  The ability to set a mask as inactive, rather than having to delete the mask.
  When dealing with a panorama with a number of moving objects, sometimes 
compromises have to be made as to what is left in and what is removed; being 
able to disable a mask would make it easer to test which options work best.

To manage notifications about this bug go to:
https://bugs.launchpad.net/hugin/+bug/940840/+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 936090] Re: cpfind does not handle matrixmode correctly.

2012-02-24 Thread Bruno Postle
I don't think you read my comment, cpfind knows how to only try and
match overlapping photos, but somebody needs to write the code to expose
it as a separate option.

Again, using an additional configuration file to specify which photos
you think overlap is excessive and unnecessary, surely it is much
simpler to specify where you think the photos should be placed and let
the software figure-out which photos should then overlap.

This way you can write a tool to suit your shooting arrangement, or a
converter to read the log file from a robot head (see papywizard), or
just drag the photos in the preview and send this layout to cpfind to
match.

We have a framework for this, this is why cpfind uses a PTO project as
input, since this way we can specify every kind of hint that a control
point generator could possibly need.

Nobody is saying that cpfind is perfect and can't be improved, clearly
it has a long way to go. The multirow option exists not because we think
it is the best way to match a panorama, but because comparing every
photo with every other photo doesn't scale, multirow makes a 400 photo
panorama practical because the multirow algorithm scales linearly with
the number of photos, whereas the default really doesn't.

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

Title:
  cpfind does not handle matrixmode correctly.

Status in Hugin - Panorama Tools GUI:
  Triaged

Bug description:
  I'm shooting panoramas in matrix mode. So I do a row, move to the next
  row and then move along the row again.

  for example 16 pictures might be taken as follows:

0   12   3  
7   65   4
8   9  10 11
  15 14 13 12

  I use the snake algorithm to reduce the amount of movement of the
  camera.

  This means that every picture n is adjacent to picture n+1,  but
  also to some picture in the next row. I haven't managed to get
  cpfind's matrixmode to analyse the correct image pairs.

  Determining which images overlap with what others is something that
  cpfind shouldn't be bothered with. I suggest cpfind implements
  linear and all modes, but nothing else.

  I have implemented a --checkmatchesfile option.  If specified cpfind
  will load the image pairs to check from the file.

  For now I manually created the pairs-file with a simple shell
  script. However the hugin fast preview layout window also knows what
  image pairs overlap. It can easily be modified to output this file! In
  my case I've also written a script that will create an initial layout
  for an empty PTO file. The fast preview/layout window will then know
  instantly which images overlap, and should be able to output a nice
  checkmatchesfile for me.

  The improvement in quality of the resulting layout is enormous! 
  (it also seems that my checkmatches list is much shorter than the matrix mode 
default, so it runs faster too. )

  
  I must admit that my C++ skills are a bit lacking. The ugliest part is in 
PanoDetector::prepareMatches . There I mostly use C to read the checkmatches 
file. Someone fluent in C++ can easily translate that to C++. 

  The patch also corrects a typo in RANSACOptimizer::Mode getRansacMode
  . (the name was setRan...)

To manage notifications about this bug go to:
https://bugs.launchpad.net/hugin/+bug/936090/+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 936836] Re: Controlpoint punching.

2012-02-23 Thread Bruno Postle
Actually, there is exactly the function you want. In the Control Points
tab, pick your two photos and press the 'g' key, this will create points
between the two photos using the current transform as a guide.

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

Title:
  Controlpoint punching.

Status in Hugin - Panorama Tools GUI:
  New

Bug description:
  I'm shooting big panos now. I'm also shooting images that contain
  nothing but sky. Controlpoints in that area are lowsy at best.

  When I've got things lined up reasonably, I would like to be able to
  say: Get me a controlpoint HERE.

  i.e. I click on the left image, and using the current transformations,
  it automatically creates a controlpoint with distance 0 with the right
  image (in the controlpoint editor).

To manage notifications about this bug go to:
https://bugs.launchpad.net/hugin/+bug/936836/+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 900654] Re: about dialog mentions gsoc 2007-2010 but not 2011

2012-02-23 Thread Bruno Postle
Changed to 'fix-committed' since 2011 was added to the list in
69e9c8988e90

** Changed in: hugin
   Status: Expired = Fix Committed

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

Title:
  about dialog mentions gsoc 2007-2010 but not 2011

Status in Hugin - Panorama Tools GUI:
  Fix Committed

Bug description:
  Hugin 2011.4 win32 ( HuginSetup_2011.4.0-rc1_32bit_Windows.exe )

  About-Sponsors dialog mentions Google Summer of Code 2007, 2008,
  2009, 2010 but not 2011, but according to http://www.google-
  melange.com/gsoc/org/google/gsoc2011/hugin Hugin also was accepted
  this year.

To manage notifications about this bug go to:
https://bugs.launchpad.net/hugin/+bug/900654/+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 938293] Re: cpfind links against system flann, but includes the bundled flann

2012-02-22 Thread Bruno Postle
Thanks, committed as 18b1029df5ba

I also had to change the levmar include in src/tools/tca_correct.cpp and
the lensdb include in src/tools/fulla.cpp

** Changed in: hugin
   Status: New = Fix Committed

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

Title:
  cpfind links against system flann, but includes the bundled flann

Status in Hugin - Panorama Tools GUI:
  Fix Committed

Bug description:
  During the build process, a system installed flann is detected fine,
  but the include lines for cpfind have these entries in this order:

   -I/path/to/builddir/src/foreign ... -I/usr/include

  The result is that although cpfind dynamically links to the system
  flann library, cpfind is actually compiled using the bundled flann
  headers. This fails on fedora f17, because it has flann-1.7.1, whereas
  Hugin HG tip bundles flann-1.6.1 headers.

  I tried fixing this by rearranging lines in CMakeLists.txt, but it
  doesn't seem to control the order of -I entries, so I don't know
  enough cmake magic.

  For the fedora package simply removing the src/foreign/flann folder
  lets me build ok, but this isn't a solution for most users.

To manage notifications about this bug go to:
https://bugs.launchpad.net/hugin/+bug/938293/+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 938293] [NEW] cpfind links against system flann, but includes the bundled flann

2012-02-21 Thread Bruno Postle
Public bug reported:

During the build process, a system installed flann is detected fine, but
the include lines for cpfind have these entries in this order:

 -I/path/to/builddir/src/foreign ... -I/usr/include

The result is that although cpfind dynamically links to the system flann
library, cpfind is actually compiled using the bundled flann headers.
This fails on fedora f17, because it has flann-1.7.1, whereas Hugin HG
tip bundles flann-1.6.1 headers.

I tried fixing this by rearranging lines in CMakeLists.txt, but it
doesn't seem to control the order of -I entries, so I don't know enough
cmake magic.

For the fedora package simply removing the src/foreign/flann folder lets
me build ok, but this isn't a solution for most users.

** Affects: hugin
 Importance: High
 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/938293

Title:
  cpfind links against system flann, but includes the bundled flann

Status in Hugin - Panorama Tools GUI:
  New

Bug description:
  During the build process, a system installed flann is detected fine,
  but the include lines for cpfind have these entries in this order:

   -I/path/to/builddir/src/foreign ... -I/usr/include

  The result is that although cpfind dynamically links to the system
  flann library, cpfind is actually compiled using the bundled flann
  headers. This fails on fedora f17, because it has flann-1.7.1, whereas
  Hugin HG tip bundles flann-1.6.1 headers.

  I tried fixing this by rearranging lines in CMakeLists.txt, but it
  doesn't seem to control the order of -I entries, so I don't know
  enough cmake magic.

  For the fedora package simply removing the src/foreign/flann folder
  lets me build ok, but this isn't a solution for most users.

To manage notifications about this bug go to:
https://bugs.launchpad.net/hugin/+bug/938293/+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 913250] Re: patch to build Hugin with gcc-4.7.0

2012-02-10 Thread Bruno Postle
The patch builds fine with gcc-4.6.1 and 4.7.0.
Commited as c7ecd541dbd7

** Changed in: hugin
   Status: Confirmed = Fix Committed

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

Title:
  patch to build Hugin with gcc-4.7.0

Status in Hugin - Panorama Tools GUI:
  Fix Committed

Bug description:
  Fedora f17 will ship with gcc-4.7.0. I needed this patch to get Hugin
  to build, can somebody check it for sanity and I'll commit it?

To manage notifications about this bug go to:
https://bugs.launchpad.net/hugin/+bug/913250/+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 921215] Re: Segmentation Fault on HDR Blend

2012-01-24 Thread Bruno Postle
Setting this as a Hugin bug since the logs show the crash is in
hugin_hdr_merge not enblend.

Though I have no solution, do you still get the crash if you try three
photos instead of seven? (just hide the other photos in the preview
window and try the stitch again)

** Also affects: hugin
   Importance: Undecided
   Status: New

** No longer affects: enblend

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

Title:
  Segmentation Fault on HDR Blend

Status in Hugin - Panorama Tools GUI:
  New

Bug description:
  After, doing what appears to be everything correctly. I run the process, and 
the log ends up as this.
  It's 6 or 7 exposure different images, that I'm trying to blend into an HDR. 
Mainly testing purposes right now.
  I keep getting a Seg Fault at the last make exr step.

  -JAG


  ===
  ***  Panorama makefile generated by Hugin   ***
  ===
  System information
  ===
  Operating system: GNU/Linux
  Release: 3.0.0-15-generic
  Kernel version: #26-Ubuntu SMP Fri Jan 20 17:23:00 UTC 2012
  Machine: x86_64
  Disc usage
  FilesystemSize  Used Avail Use% Mounted on
  /dev/sda1  55G   34G   19G  65% /
  udev  1.9G  8.0K  1.9G   1% /dev
  tmpfs 780M  1.1M  778M   1% /run
  none  5.0M 0  5.0M   0% /run/lock
  none  2.0G  1.7M  2.0G   1% /run/shm
  /dev/sdb1 466G  346G  121G  75% /media/A500
  Memory usage
   total   used   free sharedbuffers cached
  Mem:  3895   3772122  0 10218
  -/+ buffers/cache:   3544351
  Swap: 4027677   3350
  ===
  Output options
  ===
  Hugin Version: 2011.4.0.cf9be9344356
  Project file: /tmp/huginpto_F5LgOK
  Output prefix: IMG_20120124_124742-IMG_20120124_124809
  Projection: Rectilinear (0)
  Field of view: 52 x 42
  Canvas dimensions: 2620 x 2062
  Crop area: (62,113) - (2545,1932)
  Output exposure value: 14.91
  Selected outputs
  HDR merging
  * Merged and blended panorama
  ===
  Input images
  ===
  Number of images in project file: 7
  Number of active images: 7
  Image 0: 
/media/A500/Dropbox/Dropbox/Public/Photos/hdr/2/IMG_20120124_124742.jpg
  Image 0: Size 2592x1944, Exposure: 10.84
  Image 1: 
/media/A500/Dropbox/Dropbox/Public/Photos/hdr/2/IMG_20120124_124746.jpg
  Image 1: Size 2592x1944, Exposure: 12.01
  Image 2: 
/media/A500/Dropbox/Dropbox/Public/Photos/hdr/2/IMG_20120124_124751.jpg
  Image 2: Size 2592x1944, Exposure: 12.97
  Image 3: 
/media/A500/Dropbox/Dropbox/Public/Photos/hdr/2/IMG_20120124_124755.jpg
  Image 3: Size 2592x1944, Exposure: 14.12
  Image 4: 
/media/A500/Dropbox/Dropbox/Public/Photos/hdr/2/IMG_20120124_124759.jpg
  Image 4: Size 2592x1944, Exposure: 15.87
  Image 5: 
/media/A500/Dropbox/Dropbox/Public/Photos/hdr/2/IMG_20120124_124803.jpg
  Image 5: Size 2592x1944, Exposure: 18.77
  Image 6: 
/media/A500/Dropbox/Dropbox/Public/Photos/hdr/2/IMG_20120124_124809.jpg
  Image 6: Size 2592x1944, Exposure: 19.77
  ===
  Testing programs
  ===
  Checking nona...[OK]
  Checking enblend...[OK]
  Checking enfuse...[OK]
  Checking hugin_hdrmerge...[OK]
  Checking exiftool...[OK]
  ===
  Stitching panorama
  ===
  nona  -r hdr -m EXR_m -o IMG_20120124_124742-IMG_20120124_124809_hdr_ -i 0 
/tmp/huginpto_F5LgOK
  nona  -r hdr -m EXR_m -o IMG_20120124_124742-IMG_20120124_124809_hdr_ -i 1 
/tmp/huginpto_F5LgOK
  nona  -r hdr -m EXR_m -o IMG_20120124_124742-IMG_20120124_124809_hdr_ -i 2 
/tmp/huginpto_F5LgOK
  nona  -r hdr -m EXR_m -o IMG_20120124_124742-IMG_20120124_124809_hdr_ -i 3 
/tmp/huginpto_F5LgOK
  nona  -r hdr -m EXR_m -o IMG_20120124_124742-IMG_20120124_124809_hdr_ -i 4 
/tmp/huginpto_F5LgOK
  nona  -r hdr -m EXR_m -o IMG_20120124_124742-IMG_20120124_124809_hdr_ -i 5 
/tmp/huginpto_F5LgOK
  nona  -r hdr -m EXR_m -o IMG_20120124_124742-IMG_20120124_124809_hdr_ -i 6 
/tmp/huginpto_F5LgOK
  hugin_hdrmerge -m avg -c -o 
IMG_20120124_124742-IMG_20120124_124809_stack_hdr_.exr -- 

[Hugin-devs] [Bug 913250] [NEW] patch to build Hugin with gcc-4.7.0

2012-01-07 Thread Bruno Postle
Public bug reported:

Fedora f17 will ship with gcc-4.7.0. I needed this patch to get Hugin to
build, can somebody check it for sanity and I'll commit it?

** Affects: hugin
 Importance: High
 Status: New


** Tags: 4.7 build failure gcc zthread

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

Title:
  patch to build Hugin with gcc-4.7.0

Status in Hugin - Panorama Tools GUI:
  New

Bug description:
  Fedora f17 will ship with gcc-4.7.0. I needed this patch to get Hugin
  to build, can somebody check it for sanity and I'll commit it?

To manage notifications about this bug go to:
https://bugs.launchpad.net/hugin/+bug/913250/+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 913250] Re: patch to build Hugin with gcc-4.7.0

2012-01-07 Thread Bruno Postle
** Patch added: hugin-gcc47.patch
   
https://bugs.launchpad.net/bugs/913250/+attachment/2661850/+files/hugin-gcc47.patch

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

Title:
  patch to build Hugin with gcc-4.7.0

Status in Hugin - Panorama Tools GUI:
  New

Bug description:
  Fedora f17 will ship with gcc-4.7.0. I needed this patch to get Hugin
  to build, can somebody check it for sanity and I'll commit it?

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


Re: [Hugin-devs] Hugin plugin to generate 3D models

2012-01-07 Thread Bruno Postle
Hi Stephan, I think we are very interested in your work, this topic 
has been discussed a lot on the Hugin-PTX mailing list and I'm sure 
there are Hugin users (including myself) who would like to use Hugin 
for managing points for 3D model generation.


I look forward to seeing the plugin when you are ready.

--
Bruno

On Thu 05-Jan-2012 at 14:12 +0100, Stefan Wirtz wrote:


during my time as a PhD student at the University of Koblenz in Germany
I developed a plugin for Hugin (version 0.8), which might be interesting
for you. This plugin allows generating a 3D model of a building
including semantic annotations from image series.

In order to use my plugin, you first need to take overlapping pictures
of the building you want to reconstruct in 3D and then these pictures
need to be undistorted.  Afterwards, you select within Huging the point
correspondences, which are important for the geometry of the building,
from the undistorted image series.

Using structure from motion techniques, my approach is able to recover
the 3D structure and camera poses with these point correspondences. As a
result you receive 3D points, which can be grouped to surfaces and
annotated with labels like wall, window or door. For each annotated
surface the system chooses an image, cuts the surface, calculates the
homography and displays the texture on the surface. After the annotation
phase, we are able to export the semantic annotations and the associated
surfaces along with their texture information to the exchange format
CityGML, an established standard for building  representation.

The approach is accepted at the conference IST/SPIE | Electronic
Imaging and will be published in the next months.

The attached document gives an overview of the entire process. So far
the approach only works with Linux.

Other working groups deal with that issue as well. For example:

[1]  http://www.acvt.com.au/research/structure-from-image-sets/videotrace

This approach might be interesting for you, because Hugin delivers a
perfect environment for the issue of generating semantic 3D models.
Therefore, the inclusion of my approach might be an interesting
augmentation for Hugin. I would be pleased, if you see potential in that
approach. I am looking forward hearing from you.


___
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 903968] [NEW] pto_gen creates output in current working directory

2011-12-13 Thread Bruno Postle
Public bug reported:

I tried creating a pto_gen.desktop file for Linux, this would allow a
user to select multiple photos in a file browser and create a .pto
project from the right-click context menu by running pto_gen.

However this results in the .pto project being written to the users
$HOME directory since pto_gen creates the output file in the current
working directory.

e.g. this is the sort of command I need to be able to run:

  pto_gen /home/bruno/photos/P1030156.JPG
/home/bruno/photos/P1030157.JPG /home/bruno/photos/P1030158.JPG

What gets created is this file:

  P1030156-P1030158.pto

What I really need is this, i.e. the output file path needs to be
constructed from the full path of the first file:

  /home/bruno/photos/P1030156-P1030158.pto

** 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/903968

Title:
  pto_gen creates output in current working directory

Status in Hugin - Panorama Tools GUI:
  New

Bug description:
  I tried creating a pto_gen.desktop file for Linux, this would allow a
  user to select multiple photos in a file browser and create a .pto
  project from the right-click context menu by running pto_gen.

  However this results in the .pto project being written to the users
  $HOME directory since pto_gen creates the output file in the current
  working directory.

  e.g. this is the sort of command I need to be able to run:

pto_gen /home/bruno/photos/P1030156.JPG
  /home/bruno/photos/P1030157.JPG /home/bruno/photos/P1030158.JPG

  What gets created is this file:

P1030156-P1030158.pto

  What I really need is this, i.e. the output file path needs to be
  constructed from the full path of the first file:

/home/bruno/photos/P1030156-P1030158.pto

To manage notifications about this bug go to:
https://bugs.launchpad.net/hugin/+bug/903968/+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 894287] Re: hugin produces non portable jpg files

2011-11-25 Thread Bruno Postle
Although this bug is fixed in the current Hugin release, this doesn't
really help because Hugin itself usually only creates TIFF and EXR
files, the final JPEG output is typically created by enblend.

enblend had the same vigra bug and has also been fixed upstream, but
there has been no stable release with the fix yet.

Since archlinux is not likely to drop libjpeg-turbo, the solution is to
get them to patch their current enblend package.

The fedora package for enblend-4.0 has this one-line fix which disables
arithmetic coding, I recommend any distro that has adopted libjpeg-turbo
to do the same:

  sed -i 's/info.arith_code = TRUE/info.arith_code = FALSE/'
src/vigra_impex/jpeg.cxx

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

Title:
  hugin produces non portable jpg files

Status in Hugin - Panorama Tools GUI:
  New

Bug description:
  Description:
  using jpeg as output file format in hugin (instead of tiff or png) (quality 
set to 90% or 95%) produces jpg files which:
  * can be opened using gwenview 4.7.3-1, dolphin (thumbnails), Antony; i 
suspect that using Qt as toolkit handles jpg files in all these programs.
  * can not be imported to inkscape 0.48.2-4 (produces black squares) and can 
not be opened using firefox 8.0.1-1 (canvas remaines white)
  * can not be opend using IrfanView 4.30 (Error message: Decode error! Sorry, 
arithmetic coding is not implemented) or using MS image preview both under MS 
Windows 7

  The last one is not good, because i shared some panoramas with friends
  using Windows who were not able open them. Testing the Windows build
  of hugin produced jpg files which were fine on all systems.

  Searching this bug using Google i found:
  http://old.nabble.com/Error-interpreting-JPEG-file-td31789059.html
  Summary (as far as i understood it): This discussion describes basicly the 
same problem. Since a patent on arithmetic coding expired libjpeg-turbo which 
is used by hugin uses this method. They were able to produce jpg files which 
could be opened using eye-of-gnome (which was not able to open arithmentic 
encoded jpg files), by disabeling arithmetic encoding.

  According to your changelog you disabled arithmetic jpeg output:
  Bruno Postle br...@postle.net [Sun, 19 Jun 2011 22:14:52 +0100] rev 5327
  http://hugin.hg.sourceforge.net/hgweb/hugin/hugin/rev/94055f97478d

  Afterall it seems that for me this does not work in a correct way.

  kind regards
  RausH

  Additional info:
  * Archlinux (package numbers given above are with respect to the Archlinux 
package management system)
  * package version(s): hugin 2011.2.0-1

  
  Steps to reproduce:
  take some images and stitch them together using hugin. set the output file 
format to jpeg. try to open this file in various programs such as inkscape or 
firefox.

To manage notifications about this bug go to:
https://bugs.launchpad.net/hugin/+bug/894287/+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 892637] Re: Errors in translatable strings

2011-11-20 Thread Bruno Postle
 Automatic stitch projects after (successful) running assistant.

This should be like this (since 'stitch' and 'running' are both verbs):

 Automatically stitch projects after (successfully) running assistant.

Whereas here 'stitch' is a noun, so this is ok:

  Automatic stitch after assistant

Isn't English great ;-)

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

Title:
  Errors in translatable strings

Status in Hugin - Panorama Tools GUI:
  Fix Committed

Bug description:
  In the following strings I suspect (no native speaker...) some
  mistakes:

WARNING: existing files with be silently overwritten.
  - will be...

Optimizing lens distortions parameters...
  - distortion

Hugins preview window can use multiple threads for processing.\n
Set this to the number of processors or processor cores available in your 
system
  - This must be the Fast Preview window, right? Then there is an apostrophe 
missing in Hugins. The second sentence seems to need a max (the maximum 
number of processors) and lacks a full stop.

Automatic stitch projects after (successful) running assistant.
  - This string in PTBatcherGUI (checkboxes on the right) looks a bit odd to 
me...

Automatic stitch after assistant
  - same here

  And a tooltip seems to be incorrect in the Fast Preview window -
  Preview tab: if the checkbox show control points is selected, all
  CPs are shown in green, yellow and red according to their quality.
  However, the respective tooltip says Show lines between the ends of
  each control point. The longer the line, the bigger the error.

To manage notifications about this bug go to:
https://bugs.launchpad.net/hugin/+bug/892637/+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 892771] Re: Errors in Hugin-2011.4.0 Release Notes

2011-11-20 Thread Bruno Postle
Looks good, I've committed it.

** Changed in: hugin
   Status: New = Fix Committed

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

Title:
  Errors in Hugin-2011.4.0 Release Notes

Status in Hugin - Panorama Tools GUI:
  Fix Committed

Bug description:
  I found several errors in the current version of the Hugin-2011.4.0
  Release Notes and tried to correct them in the attached file.
  Hopefully a native speaker can take some time to review this. Thanks.

To manage notifications about this bug go to:
https://bugs.launchpad.net/hugin/+bug/892771/+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 891912] Re: Mask rendering issue with full-frame fisheye lens for 360 pano

2011-11-18 Thread Bruno Postle
Confirmed with  2011.3.0 2011-10-31hg on Linux. I'll attach a reduced
2-image project with dummy photos that shows the problem.

** Attachment added: mask-test.zip
   
https://bugs.launchpad.net/hugin/+bug/891912/+attachment/2601254/+files/mask-test.zip

** Changed in: hugin
   Status: New = Confirmed

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

Title:
  Mask rendering issue with full-frame fisheye lens for 360 pano

Status in Hugin - Panorama Tools GUI:
  Confirmed

Bug description:
  pto attached that highlights the problem.

  email sent to hugin-ptx yesterday:

  ===
  Hi there!

  I'm experiencing a very weird behavior in hugin 2011.2.0 on a gentoo
  64 box. I have a 360 pano of 15 shots taken with a full frame fisheye
  10.5mm. There are so many shots because I am doing a clone photography
  experiment of the same subject several times in the pano.

  I've set up masks accordingly to include the subject in all relevant
  shots. masks do not overlap accross shots.

  For 2 of the shots, where the subject is roughly 180 degree from
  himself, enabling both pics at the same time with masks gives me a
  completely wrong masking result (both in hugin and as exported by nona
  on stitching).

  I have a taken a few screenshots showing the problem here:
  http://timotheegroleau.com/bugs/2016_hugin_mask/

  note the incorrect render when both pics are activated simultaneously.

  Has anyone experienced this before? How can I troubleshoot and fix
  this?

  Thanks in advance!
  Tim
  ===

  reply from Bruno Postle
  ===
  Yes we have seen and fixed similar bugs with masks and fisheye
  photos before.  The workaround is to just edit the mask and move
  some nodes, the problem should go away.

  ..but before you do that please save the .pto file and attach it to a
  bug report on launchpad: https://bugs.launchpad.net/hugin/+filebug
  ===

  
  I have tried to edit the masks to be as close as possible to the subjects 
outline, I can't get the problem to go away :(

To manage notifications about this bug go to:
https://bugs.launchpad.net/hugin/+bug/891912/+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 890444] Re: hugin crashes on start (arch, catalyst, scrotwm)

2011-11-16 Thread Bruno Postle
I think the catalyst driver is the old ATI proprietary driver, can you
try with the current open source ATI drivers and see if it works with
that?

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

Title:
  hugin crashes on start (arch, catalyst, scrotwm)

Status in Hugin - Panorama Tools GUI:
  New

Bug description:
  Info from Help-About:
  Operating System: Linux 3.1.0-4-ARCH x86_64
  Architecture: 64 bit
  Free memory: 907780 kiB

  Hugin
  Version: 2011.2.0.3d9649aa241a
  Path to resources: /usr/share/hugin/xrc/
  Path to data: /usr/share/hugin/data/

  
  If I try to start hugin, I get

  The program 'hugin' received an X Window System error.
  This probably reflects a bug in the program.
  The error was 'BadMatch (invalid parameter attributes)'.
(Details: serial 734 error_code 8 request_code 156 minor_code 5)
  ... bla ... debug on gdk_x_error.

  I browsed through the code a little and managed to start hugin if I comment 
out the lines
  // AddLabelToBitmapButton(select_all,_(All),false);
  // AddLabelToBitmapButton(select_none,_(None), false);
  from GLPreviewFrame.cpp (line 374+375)

  Without this fix, I get the error mentioned above, and the backtrace from 
gdk_x_error is:
  #0  gdk_x_error (display=0x94a400, error=0x7fffcf60) at gdkmain-x11.c:458
  #1  0x70348e3b in _XError (dpy=0x94a400, rep=0x1257ae0) at 
XlibInt.c:1583
  #2  0x70346479 in handle_error (dpy=0x94a400, err=0x1257ae0, 
in_XReply=optimized out) at xcb_io.c:212
  #3  0x703464e9 in handle_response (dpy=0x94a400, response=0x1257ae0, 
in_XReply=optimized out) at xcb_io.c:324
  #4  0x70346d48 in _XReply (dpy=0x94a400, rep=0x7fffd100, extra=0, 
discard=1) at xcb_io.c:626
  #5  0x70342791 in XSync (dpy=0x94a400, discard=0) at Sync.c:44
  #6  0x70342816 in _XSyncFunction (dpy=optimized out) at Synchro.c:35
  #7  0x7fffeca73903 in gdk_x11_drawable_update_picture_clip (gc=0xd75030, 
drawable=0x123bea0) at gdkdrawable-x11.c:405
  #8  gdk_x11_draw_pixbuf (drawable=0x123bea0, gc=0xd75030, pixbuf=0x1242f20, 
src_x=0, src_y=0, dest_x=0, dest_y=0, width=22, 
  height=22, dither=GDK_RGB_DITHER_NORMAL, x_dither=0, y_dither=0) at 
gdkdrawable-x11.c:1503
  #9  0x7fffeca41d7a in IA__gdk_draw_pixbuf (drawable=0x123bea0, 
gc=0xd75030, pixbuf=0x1242f20, src_x=0, src_y=0, dest_x=0, 
  dest_y=0, width=22, height=22, dither=GDK_RGB_DITHER_NORMAL, x_dither=0, 
y_dither=0) at gdkdraw.c:834
  #10 0x7fffeca4d8d1 in gdk_pixmap_draw_pixbuf (drawable=0x1257c60, 
gc=0xd75030, pixbuf=0x1242f20, src_x=0, src_y=0, dest_x=0, 
  dest_y=0, width=22, height=22, dither=GDK_RGB_DITHER_NORMAL, x_dither=0, 
y_dither=0) at gdkpixmap.c:499
  #11 0x7fffeca41d7a in IA__gdk_draw_pixbuf (drawable=0x1257c60, 
gc=0xd75030, pixbuf=0x1242f20, src_x=0, src_y=0, dest_x=0, 
  dest_y=0, width=22, height=22, dither=GDK_RGB_DITHER_NORMAL, x_dither=0, 
y_dither=0) at gdkdraw.c:834
  #12 0x7266cf4e in wxWindowDC::DoDrawBitmap(wxBitmap const, int, int, 
bool) () from /usr/lib/libwx_gtk2u_core-2.8.so.0
  #13 0x00550764 in DrawBitmap (bmp=..., useMask=true, y=0, x=0, 
this=0x7fffd500) at /usr/include/wx-2.8/wx/dc.h:271
  #14 AddLabelToBitmapButton (button=0x1254040, new_label=..., 
TextBelow=optimized out)
  at 
/home/j/ABS/hugin/src/hugin-2011.2.0/src/hugin1/hugin/GLPreviewFrame.cpp:225
  #15 0x0055c4b9 in GLPreviewFrame::GLPreviewFrame (this=0x11d9b20, 
frame=optimized out, pano=...)
  at 
/home/j/ABS/hugin/src/hugin-2011.2.0/src/hugin1/hugin/GLPreviewFrame.cpp:374
  #16 0x004a04ae in MainFrame::MainFrame (this=0x9f8b40, parent=0x0, 
pano=...)
  at /home/j/ABS/hugin/src/hugin-2011.2.0/src/hugin1/hugin/MainFrame.cpp:398
  #17 0x0048a75b in huginApp::OnInit (this=0x926f50)
  at /home/j/ABS/hugin/src/hugin-2011.2.0/src/hugin1/hugin/huginApp.cpp:294
  #18 0x72b1649b in wxEntry(int, wchar_t**) () from 
/usr/lib/libwx_baseu-2.8.so.0
  #19 0x00486842 in main (argc=2, argv=optimized out)
  at /home/j/ABS/hugin/src/hugin-2011.2.0/src/hugin1/hugin/huginApp.cpp:115

To manage notifications about this bug go to:
https://bugs.launchpad.net/hugin/+bug/890444/+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 887406] Re: Mask indications from other layers move with scrolling

2011-11-08 Thread Bruno Postle
I can't reproduce on Linux. Can you upload the .pto project that shows
the problem? (no need to upload the photos).

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

Title:
  Mask indications from other layers move with scrolling

Status in Hugin - Panorama Tools GUI:
  New

Bug description:
  I suppose could be related to the other bug I reported about
  difficulties with editing masks in Hugin on the Mac.

  When in mask tab, if the image is larger than the image area, the
  indicated areas of masks from other layers do not stay registered with
  the image when the scrollbars are moved. It would also be nice if the
  scroll bars would stay in their last position when you click another
  photo in the project and then come back (instead of snapping pack to
  the top left.)

  Attached small screen screenshots. Placed them in a pdf and mad the file 
small. If you need higher quality let me know.
  p.1) fit in window view
  p.2-4) zoomed vies showing change with scrolling.

  Using Hugin 2011.3.0.5558:a7863c364ae9 (Mac)

  System Software Overview:

System Version: Mac OS X 10.6.8 (10K549)
Kernel Version: Darwin 10.8.0
Boot Volume:Big Nigel
Boot Mode:  Normal
Computer Name:
User Name:
Secure Virtual Memory:  Enabled
64-bit Kernel and Extensions:   No
Time since boot:20:56

  
  Hardware Overview:

Model Name: MacBook Pro
Model Identifier:   MacBookPro3,1
Processor Name: Intel Core 2 Duo
Processor Speed:2.4 GHz
Number Of Processors:   1
Total Number Of Cores:  2
L2 Cache:   4 MB
Memory: 4 GB
Bus Speed:  800 MHz
Boot ROM Version:   MBP31.0070.B07
SMC Version (system):   1.18f5
Serial Number (system):
Hardware UUID:
Sudden Motion Sensor:
State:  Enabled

To manage notifications about this bug go to:
https://bugs.launchpad.net/hugin/+bug/887406/+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 868475] Re: Translated nadir image not mapping correctly

2011-10-06 Thread Bruno Postle
OK, added to the FAQ:
http://wiki.panotools.org/Hugin_FAQ#Patching_nadir_shots_using_XYZ_mosaic_mode_cuts_the_photos_in_half

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

Title:
  Translated nadir image not mapping correctly

Status in Hugin - Panorama Tools GUI:
  Invalid

Bug description:
  If an image is mapped to the nadir of a panorama and all translation
  parameters (X,Y,Z) are set to zero, the image is properly mapped and
  covers the entire nadir of the shot.

  However, if any of the X,Y,Z parameters are non-zero, then the image
  is cut in half and only occupies half of the nadir.

  This bug appears both in the preview and in the final image and is
  important because, typically, the nadir shot is handheld and non-zero
  X,Y,Z parameters can improve the fit.

To manage notifications about this bug go to:
https://bugs.launchpad.net/hugin/+bug/868475/+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 868475] Re: Translated nadir image not mapping correctly

2011-10-05 Thread Bruno Postle
Basically the XYZ mosaic mode as it is implemented currently in Hugin
requires that the mosaic photos must be mapped to a plane perpendicular
to the view direction - In practice this means that what you are trying
to do only works if the panorama is rotated such that the nadir is in
the middle of the canvas and not at the bottom.

This isn't so bad, the nadir-in-the-middle image looks a bit weird, you
can just reload the stitched equirectangular result into a new single-
photo project and straighten it there.

There is code in libpano13 to do this rotation all in one go, but it
isn't enabled in Hugin - I would be concerned that it would be way to
confusing - The two step stitching is conceptually easier.

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

Title:
  Translated nadir image not mapping correctly

Status in Hugin - Panorama Tools GUI:
  New

Bug description:
  If an image is mapped to the nadir of a panorama and all translation
  parameters (X,Y,Z) are set to zero, the image is properly mapped and
  covers the entire nadir of the shot.

  However, if any of the X,Y,Z parameters are non-zero, then the image
  is cut in half and only occupies half of the nadir.

  This bug appears both in the preview and in the final image and is
  important because, typically, the nadir shot is handheld and non-zero
  X,Y,Z parameters can improve the fit.

To manage notifications about this bug go to:
https://bugs.launchpad.net/hugin/+bug/868475/+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 847433] Re: 'Create panorama' is disabled in single photo projects

2011-09-29 Thread Bruno Postle
I hadn't noticed there is still a Stitch! button in the Stitcher tab, it
had just moved to the corner where I lost it, so this isn't so critical.

Though I think the Assistant is still too strict, Align... with a single
photo should run linefind, level and crop, this is something that a user
should want to then stitch.

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

Title:
  'Create panorama' is disabled in single photo projects

Status in Hugin - Panorama Tools GUI:
  New

Bug description:
  When starting a project, both 2. Align... and 3. Create panorama are
  greyed out which makes sense.

  However if I load a single photo into Hugin, they are still greyed.
  This is a problem as a common use of Hugin for me is to load a single
  image and remap it to a different projection.

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


Re: [Hugin-devs] [Bug 792896] Re: Fast Preview Hangs or Crashes since 2011.0

2011-09-06 Thread Bruno Postle
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Sat 20-Aug-2011 at 09:43 -, Lukas Jirkovsky wrote:

 A first one is a hang in libpano math.c, line 297:
while( *x_src   var0 )
*x_src -= 2 *  var0;
 because *x_src = 2.17213129256892e+98 and var0 = 
 13652.608695652176. If my computations are correct, *x_src never 
 changes because of the underflow. I'm able to reproduce this 
 problem with one panorama in approximately one quarter of tests.

I don't see this bug in action even though it is clearly asking for 
trouble.  Could it only appear on a particular architecture? or 
maybe there is something in the default fedora gcc flags that 
prevents the underflow.

Can you provide a patch for libpano13?

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.6 (GNU/Linux)

iD8DBQFOZoJ0FqOhwCjyCLoRAh1RAKCbgqX76YW/qjAS6C7LsjMaLJl0SQCguDf1
8d/0Ku+qbc+FCAkD9EtWTKU=
=76/c
-END PGP SIGNATURE-

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

Title:
  Fast Preview Hangs or Crashes since 2011.0

Status in Hugin - Panorama Tools GUI:
  Confirmed

Bug description:
  EDIT (August 6, 2011): summarized known information

  *WORKAROUND FOR USERS*: disable the Overview

  1- start Hugin
  2- load a project
  3- go to the Fast Preview Window.  don't touch anything else but described 
below as this could trigger the bug
  4- hit the button Show/Hide to hide the Overview
  5- quit Hugin
  Now Hugin should perform well.

  
  *AFFECTED SYSTEMS*

  - CPU: all systems with more than one thread, that is multi-core CPUs as well 
as single-core CPUs with hyperthreading.
  - Operating Systems: due to the different implementations of threading and 
OpenGL on different platform, some systems are more prone to error than others. 
 Mac OS X seems to be the least affected.  Windows seems to be the most 
affected.

  
  *AFFECTED VERSIONS*

  - All versions of Hugin since the introduction of the Overview in the Fast 
Preview are affected.  That is, all versions after revision 4808:8c577b320714 
2011-01-09 12:21:18
  - This includes the final releases of 2011.0.0 as well as all beta/candidate 
releases of 2011.2.0

  
  *SUMMARY FOR DEVELOPERS / BUG HUNTERS*

  This is most likely a threading issue. Lukáš' hypothesis: a race
  condition in OpenGL calls, when OGL is called by separate threads from
  both overview and fast preview. The reason is that OpenGL is not
  thread-safe and it can cause various problems when used within multi-
  threaded application.

  Run 'valgrind --tool=helgrind hugin' and try to reproduce the error to
  produce a useful backtrace like
  https://bugs.launchpad.net/hugin/+bug/792896/+attachment/2253077/+files
  /valgrind-out.txt

  
  *ORIGINAL BUG REPORT BELOW FOR COMPLETION:*

  Upgraded from 2010.4 to 2011.0.0 and it has hung 3 times in about 15
  sessions.  All three hangs happened while doing the same thing.
  new session, load images, load a lens profile, set the canvas size
  (Calculate optimal size), save-as and save profile then click on GL
  (fast preview) button.  Fast preview window comes up, shows anchor
  image and then hangs.

  Is not reproducible.  Running 2011.0.0.0fd3e119979c built by Matthew
  Petroff on 64-bit Win7.

To manage notifications about this bug go to:
https://bugs.launchpad.net/hugin/+bug/792896/+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 825756] Re: Stitching fails with multiple cores

2011-08-13 Thread Bruno Postle
The '--' is a convention used by lots of tools to separate command-line
parameters from filenames, this was added to the enblend call because
people were trying to stitch photos that had paths beginning with '-'.

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

Title:
  Stitching fails with multiple cores

Status in Hugin - Panorama Tools GUI:
  New

Bug description:
  Stitching fails when two cpu cores available as per attachment:

  If I load windows with only one core available (/onecpu switch)
  stitching always succeeds.

  Windows XP Pro SP3 – GeForce 9600GT – Drv Nvidia 275.33
  Hugin 2011.0.0.0fd3e119979c

To manage notifications about this bug go to:
https://bugs.launchpad.net/hugin/+bug/825756/+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 792896] Re: Fast Preview Hangs or Crashes since 2011.0

2011-08-04 Thread Bruno Postle
Just adding my experience:

I don't see this bug at all on fedora, though I run Hugin on a single
core laptop and a single CPU VM so I wouldn't encounter the bug if it
was a threading/multicore issue.

I had a chance a couple of days ago to try a recent Windows snapshot on
a two-core macbook runnning windows:

cpfind crashed randomly, matching two photos was ok, but four photos
crashed about 50% of the time.

The fast preview crashed Hugin repeatedly. I got it working by launching
Hugin with an empty project, and disabling the overview in the fast
preview using the Show/Hide button, after this the preview was fine.
Note that the overview had to be disabled immediately, just resizing or
moving the fast preview window caused a crash.

After this it was even possible to create a project then enable and use
the overview in the fast preview, however if I closed Hugin with the
overview enabled then Hugin was broken again after restarting.

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

Title:
  Fast Preview Hangs or Crashes since 2011.0

Status in Hugin - Panorama Tools GUI:
  Confirmed

Bug description:
  Upgraded from 2010.4 to 2011.0.0 and it has hung 3 times in about 15
  sessions.  All three hangs happened while doing the same thing.
  new session, load images, load a lens profile, set the canvas size
  (Calculate optimal size), save-as and save profile then click on GL
  (fast preview) button.  Fast preview window comes up, shows anchor
  image and then hangs.

  Is not reproducible.  Running 2011.0.0.0fd3e119979c built by Matthew
  Petroff on 64-bit Win7.

To manage notifications about this bug go to:
https://bugs.launchpad.net/hugin/+bug/792896/+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 816022] Re: Error during stitching (no rule to make target)

2011-07-25 Thread Bruno Postle
Hi, the error is literally that Hugin can't find the first input photo
which it is expecting to find here:

  /home/patrick/Need Processing/Pictures/Panorama groups/Oxford City
Hall/100_6689.JPG

Does this file exist with the exact same path? The spaces in the path
shouldn't be a problem.

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

Title:
  Error during stitching (no rule to make target)

Status in Hugin - Panorama Tools GUI:
  New

Bug description:
  Trying to stitch a panorama under Linux Mint (Julia), I get a message
  Error during stitching, please report the complete text to ... etc.
  I have verified that there are no special characters (as described by
  the FAQ entry) anywhere in the path name).

  Checking nona...[OK]
  Checking enblend...[OK]
  Checking enfuse...[OK]
  Checking hugin_hdrmerge...[OK]
  Checking exiftool...[OK]
  make: *** No rule to make target `/home/patrick/Need 
Processing/Pictures/Panorama groups/Oxford City Hall/100_6689.JPG', needed by 
`OxfordCityHall.tif'.  Stop.

To manage notifications about this bug go to:
https://bugs.launchpad.net/hugin/+bug/816022/+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 815608] [NEW] Batch processor search directory for images is non-deterministic

2011-07-24 Thread Bruno Postle
Public bug reported:

If I use Batch processor or File - Search Directory For... - Images,
and pick a folder, I get different numbers of detected panoramas each
time I click 'Start'.

i.e. I can get 0, 1, 2 or 3 detected panoramas in the same folder with
the same set of photos.

** 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/815608

Title:
  Batch processor search directory for images is non-deterministic

Status in Hugin - Panorama Tools GUI:
  New

Bug description:
  If I use Batch processor or File - Search Directory For... - Images,
  and pick a folder, I get different numbers of detected panoramas each
  time I click 'Start'.

  i.e. I can get 0, 1, 2 or 3 detected panoramas in the same folder with
  the same set of photos.

To manage notifications about this bug go to:
https://bugs.launchpad.net/hugin/+bug/815608/+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 814462] Re: German Translation

2011-07-22 Thread Bruno Postle
A .po file isn't technically a patch (you can alternatively create a
patch that just contains your changes to the .po file), but for the bug
tracker it has the same purpose as a patch.

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

Title:
  German Translation

Status in Hugin - Panorama Tools GUI:
  New

Bug description:
  Updated German translation for 2011.2.0 changeset 5434 by Carl von
  Einem

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


  1   2   >