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
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
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
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
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)
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
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
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'
** 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:
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
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
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
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
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
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.
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
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
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
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
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
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:
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
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/
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
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
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
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
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
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
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
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
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
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
-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
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
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
-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:
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
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)
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
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)
--
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
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
.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
*** 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
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
-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
-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
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
-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
-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
-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
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
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
-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
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.
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
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.
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
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
**
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
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
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
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
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
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:
** 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
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
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
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
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
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
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
** 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:
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
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,
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
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
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,
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:
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
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
** 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
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
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
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
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
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
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
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.
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
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:
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
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
-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.
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,
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
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
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
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
1 - 100 of 187 matches
Mail list logo
