[Hugin-devs] [Bug 1709473] Re: Enfuse: artifacts - false colored pixels in dark regions
Carl,
The weird, bright pixels in dark areas are artifacts of the
LCMS color-conversions in so called open color spaces. Experience has
shown that it is hard to catch all of them. However, Enblend/Enfuse
have a lot of (undocumented) command-line parameters that control the
hedging of those outliers. Please take a look at source file
"fixmath.h" in the "src" directory and check out for example `class
OptimizableLuminanceSpace'. You can control _everything_ coded as
`parameter::as_*("foo-bar", ...)' from the command line, for example
the code reads
parameter::as_boolean("mark-freaky-color-conversions", false)
so, you could say
--parameter=mark-freaky-color-conversions=true
at the command line.
For a better understanding of what is going on in the color-space
conversion steps you will probably want to compile your Enblend and
Enfuse with `LOG_COLORSPACE_CONVERSION' or even
`LOG_COLORSPACE_CONVERSION_DETAIL'. The make(1) variable
`EXTRACPPFLAGS' was made for endeavors like this:
EXTRACPPFLAGS='-DLOG_COLORSPACE_CONVERSION
-DLOG_COLORSPACE_CONVERSION_DETAIL'
Otherwise it will be enfusing-by-night.
On the technical side: all operations in "fixmath.h" only consider a
single, isolated pixel. We could think of a median filter or a
Kuwahara filter that operates on a N-times-N region of pixels at a
later processing step that mops up the outliers without impacting the
"good" pixels too much. Please send me your patches, if this idea
works out!
/cls
--
You received this bug notification because you are a member of Hugin
Developers, which is subscribed to Enblend.
https://bugs.launchpad.net/bugs/1709473
Title:
Enfuse: artifacts - false colored pixels in dark regions
Status in Enblend:
New
Bug description:
enfuse sometimes produces false colored pixels around dark regions
using the default options.
When using the option "--blend-colorspace=identity" the artefacts
don't show (at least with the attached example images).
Tested with version 4.2 and 4.3-e93b798a0c5f. The artefacts show with
both versions, although there are differences.
Attached are sample images and the result images after using the included
script. There is also a self-compiled binary of the enfuse version
4.3-e93b798a0c5f and a text file ("Info.txt") containing info about versions,
operating system and hardware.
The result images
"default.tif" and "default_dev.tif"
are the images made with default options,
the images
"identity.tif" and "identity_dev.tif"
are made with the option "--blend-colorspace=identity".
The images
"default_dev.tif"and "identity_dev.tif" are made with the development version
4.3-e93b798a0c5f
To manage notifications about this bug go to:
https://bugs.launchpad.net/enblend/+bug/1709473/+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 1702119] Re: selector.cc: 2 * bad catch type ?
Fixed in rev 1c815a028afc. ** Changed in: enblend Status: New => Fix Committed ** Changed in: enblend Importance: Undecided => Low ** Changed in: enblend Assignee: (unassigned) => Christoph Spiel (cspiel) -- You received this bug notification because you are a member of Hugin Developers, which is subscribed to Enblend. https://bugs.launchpad.net/bugs/1702119 Title: selector.cc: 2 * bad catch type ? Status in Enblend: Fix Committed Bug description: selector.cc:490:21: warning: catching polymorphic type 'class std::invalid_argument' by value [-Wcatch-value=] selector.cc:494:21: warning: catching polymorphic type 'class std::out_of_range' by value [-Wcatch-value=] Suggest catch polymorphic types by const reference, not value. To manage notifications about this bug go to: https://bugs.launchpad.net/enblend/+bug/1702119/+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 1649122] Re: Enfuse brightness mismatch in deghosted area
I stand corrected. Thanks go to Thomas for poining out what I ignored! The documentation was corrected accordingly in rev f0304648cc0f. See http://hg.code.sf.net/p/enblend/code/rev/f0304648cc0f The crucial change is the restriction in the sentence "Enblend and Enfuse simply copy the pixels of this region to the output image ***if they are away far enough from the overlap area***." In particular, my explanation for your Enfuse example was wrong. All your images overlap completely and the small masked out portion is certainly influenced by all other images through the Gaussian pyramids as explained in the fixed documentation. Sorry for the mess. -- You received this bug notification because you are a member of Hugin Developers, which is subscribed to Enblend. https://bugs.launchpad.net/bugs/1649122 Title: Enfuse brightness mismatch in deghosted area Status in Enblend: Fix Committed Bug description: Enfuse results in a brightness mismatch of dark deghosted areas when exposure-mu is decreased from its default value. Program Version: - enfuse 4.1.3 (could not compile 4.2) Platforms: - Debian Jessie - OS X 10.11.6 via MacPorts == Testcase Files == https://www.dropbox.com/sh/8la13xukmfamjk5/AACI6mruatMEsZ27wZgl8ysha?dl=0 Bracketed exposures: 161022_tc2_7079.tif - RGBA 161022_tc2_7081.tif - RGBA 161022_tc2_7083.tif - RGBA 161022_tc2_7085.tif - RGBA 161022_tc2_7086.tif - RGB Enfused results: 161022_mu00.tif - exposure-mu=0.0 161022_mu02.tif - exposure-mu=0.2 161022_mu05.tif - exposure-mu=0.5 (default) Commands to reproduce: $ enfuse --exposure-mu=0.0 -o 161022_mu00.tif 161022_tc2_70??.tif $ enfuse --exposure-mu=0.2 -o 161022_mu02.tif 161022_tc2_70??.tif $ enfuse --exposure-mu=0.5 -o 161022_mu05.tif 161022_tc2_70??.tif == Detailed Description == Deghosting; All exposures except the lightest one (..7086) share the same alpha channel which masks a dark area in the middle of the image for deghosting of moving leaves. The masking is binary, there are no partially masked pixels. When I change the exposure-mu parameter from its default 0.5 to a smaller value to darken the image, the deghosted area stays much lighter than its surroundings. The problem does not occur when deghosting a bright area using pixels from a dark exposure. To manage notifications about this bug go to: https://bugs.launchpad.net/enblend/+bug/1649122/+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 1649122] Re: Enfuse brightness mismatch in deghosted area
Thanks for reviewing the patch! Just to demonstrate the power of the multi-level blending: Again set mu=0 and _reduce_ the number of blend levels with option `--levels'. You'll find your masked tree sticking out of the darkness much more prominently. By default both Enblend and Enfuse maximize the number of levels for each overlapping region (see documentation for details). ** Changed in: enblend Status: In Progress => Fix Committed -- You received this bug notification because you are a member of Hugin Developers, which is subscribed to Enblend. https://bugs.launchpad.net/bugs/1649122 Title: Enfuse brightness mismatch in deghosted area Status in Enblend: Fix Committed Bug description: Enfuse results in a brightness mismatch of dark deghosted areas when exposure-mu is decreased from its default value. Program Version: - enfuse 4.1.3 (could not compile 4.2) Platforms: - Debian Jessie - OS X 10.11.6 via MacPorts == Testcase Files == https://www.dropbox.com/sh/8la13xukmfamjk5/AACI6mruatMEsZ27wZgl8ysha?dl=0 Bracketed exposures: 161022_tc2_7079.tif - RGBA 161022_tc2_7081.tif - RGBA 161022_tc2_7083.tif - RGBA 161022_tc2_7085.tif - RGBA 161022_tc2_7086.tif - RGB Enfused results: 161022_mu00.tif - exposure-mu=0.0 161022_mu02.tif - exposure-mu=0.2 161022_mu05.tif - exposure-mu=0.5 (default) Commands to reproduce: $ enfuse --exposure-mu=0.0 -o 161022_mu00.tif 161022_tc2_70??.tif $ enfuse --exposure-mu=0.2 -o 161022_mu02.tif 161022_tc2_70??.tif $ enfuse --exposure-mu=0.5 -o 161022_mu05.tif 161022_tc2_70??.tif == Detailed Description == Deghosting; All exposures except the lightest one (..7086) share the same alpha channel which masks a dark area in the middle of the image for deghosting of moving leaves. The masking is binary, there are no partially masked pixels. When I change the exposure-mu parameter from its default 0.5 to a smaller value to darken the image, the deghosted area stays much lighter than its surroundings. The problem does not occur when deghosting a bright area using pixels from a dark exposure. To manage notifications about this bug go to: https://bugs.launchpad.net/enblend/+bug/1649122/+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 1649122] Re: Enfuse brightness mismatch in deghosted area
> Perhaps this adaptation mechanism at the border ceases > to work when the exposure is too far off. There might > even be a built-in limit to prevent side-effects like > increased noise. Neither is there an `adaptation mechanism' nor a `built-in limit'. What you see is just the Mertens/Kautz/van Reeth algorithm at work. If you dig deeper in this issue database you may even find a bug report where Enblend did not exactly reproduce the parts of the images that were not overlapping. Please review change http://hg.code.sf.net/p/enblend/code/rev/04948f29c8ed where I added some clarifying paragraphs to the documentation. ** Changed in: enblend Status: Triaged => In Progress ** Changed in: enblend Importance: Undecided => Low -- You received this bug notification because you are a member of Hugin Developers, which is subscribed to Enblend. https://bugs.launchpad.net/bugs/1649122 Title: Enfuse brightness mismatch in deghosted area Status in Enblend: In Progress Bug description: Enfuse results in a brightness mismatch of dark deghosted areas when exposure-mu is decreased from its default value. Program Version: - enfuse 4.1.3 (could not compile 4.2) Platforms: - Debian Jessie - OS X 10.11.6 via MacPorts == Testcase Files == https://www.dropbox.com/sh/8la13xukmfamjk5/AACI6mruatMEsZ27wZgl8ysha?dl=0 Bracketed exposures: 161022_tc2_7079.tif - RGBA 161022_tc2_7081.tif - RGBA 161022_tc2_7083.tif - RGBA 161022_tc2_7085.tif - RGBA 161022_tc2_7086.tif - RGB Enfused results: 161022_mu00.tif - exposure-mu=0.0 161022_mu02.tif - exposure-mu=0.2 161022_mu05.tif - exposure-mu=0.5 (default) Commands to reproduce: $ enfuse --exposure-mu=0.0 -o 161022_mu00.tif 161022_tc2_70??.tif $ enfuse --exposure-mu=0.2 -o 161022_mu02.tif 161022_tc2_70??.tif $ enfuse --exposure-mu=0.5 -o 161022_mu05.tif 161022_tc2_70??.tif == Detailed Description == Deghosting; All exposures except the lightest one (..7086) share the same alpha channel which masks a dark area in the middle of the image for deghosting of moving leaves. The masking is binary, there are no partially masked pixels. When I change the exposure-mu parameter from its default 0.5 to a smaller value to darken the image, the deghosted area stays much lighter than its surroundings. The problem does not occur when deghosting a bright area using pixels from a dark exposure. To manage notifications about this bug go to: https://bugs.launchpad.net/enblend/+bug/1649122/+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 1649122] Re: Enfuse brightness mismatch in deghosted area
Thank you for a report in exemplary form. The small input image sizes in particular are highly appreciated! Enfuse weights each *overlapping* pixel of the input images at that very pixel. Naturally, if there is no overlap, there is nothing to weight. The extreme case is no pixels at all, a hole in the image and then your case where only a single image participates because of masking out all others or, generally no image overlap. Enfuse (and Enblend) simply copy solitary pixels to the output image *unchanged*. We could even issue a warning on this case: "Nothing to fuse" or "Nothing to blend". In your example the problem is homegrown by masking out all but one image. The luminance match for the default exposure optimum stems from the non-masked image falling well into the maximum of the Gaussian with mu=.5. If you want to stick with your workflow and still want a different mu, choose as un-masked image the one that best matches your desired mu. ** Changed in: enblend Assignee: (unassigned) => Christoph Spiel (cspiel) ** Changed in: enblend Status: New => Triaged -- You received this bug notification because you are a member of Hugin Developers, which is subscribed to Enblend. https://bugs.launchpad.net/bugs/1649122 Title: Enfuse brightness mismatch in deghosted area Status in Enblend: Triaged Bug description: Enfuse results in a brightness mismatch of dark deghosted areas when exposure-mu is decreased from its default value. Program Version: - enfuse 4.1.3 (could not compile 4.2) Platforms: - Debian Jessie - OS X 10.11.6 via MacPorts == Testcase Files == https://www.dropbox.com/sh/8la13xukmfamjk5/AACI6mruatMEsZ27wZgl8ysha?dl=0 Bracketed exposures: 161022_tc2_7079.tif - RGBA 161022_tc2_7081.tif - RGBA 161022_tc2_7083.tif - RGBA 161022_tc2_7085.tif - RGBA 161022_tc2_7086.tif - RGB Enfused results: 161022_mu00.tif - exposure-mu=0.0 161022_mu02.tif - exposure-mu=0.2 161022_mu05.tif - exposure-mu=0.5 (default) Commands to reproduce: $ enfuse --exposure-mu=0.0 -o 161022_mu00.tif 161022_tc2_70??.tif $ enfuse --exposure-mu=0.2 -o 161022_mu02.tif 161022_tc2_70??.tif $ enfuse --exposure-mu=0.5 -o 161022_mu05.tif 161022_tc2_70??.tif == Detailed Description == Deghosting; All exposures except the lightest one (..7086) share the same alpha channel which masks a dark area in the middle of the image for deghosting of moving leaves. The masking is binary, there are no partially masked pixels. When I change the exposure-mu parameter from its default 0.5 to a smaller value to darken the image, the deghosted area stays much lighter than its surroundings. The problem does not occur when deghosting a bright area using pixels from a dark exposure. To manage notifications about this bug go to: https://bugs.launchpad.net/enblend/+bug/1649122/+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 1647215] Re: Problems building current default
** Changed in: enblend Status: New => Won't Fix -- You received this bug notification because you are a member of Hugin Developers, which is subscribed to Enblend. https://bugs.launchpad.net/bugs/1647215 Title: Problems building current default Status in Enblend: Won't Fix Bug description: Attempting to build the current default (1491:24c37812cde3) on Fedora 25 x86_64, using rpmbuild and cmake. Problems occur in the docs stage. The last part of the rpmbuild log, leading up to the first reported problem, is attached. I'll provide the full rpmbuild log if needed, but thought this may be sufficient to provide clues. The rpmbuild spec file is unchanged from that used to successfully build 1488:882d3ccba621. To manage notifications about this bug go to: https://bugs.launchpad.net/enblend/+bug/1647215/+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 1647215] Re: Problems building current default
The Autoconf/Automake and the CMake generated Makefiles both build the documentation up to and including the PostScript targets by default. We intentionally avoid PDF for the default target -- obviously for good reasons. If packagers trigger the PDF targets it is their problem. I'm inclined to stick with the current behavior of your Makefiles and set this issue's status to "Won't Fix". @Terry: Do we need another resolution? -- You received this bug notification because you are a member of Hugin Developers, which is subscribed to Enblend. https://bugs.launchpad.net/bugs/1647215 Title: Problems building current default Status in Enblend: New Bug description: Attempting to build the current default (1491:24c37812cde3) on Fedora 25 x86_64, using rpmbuild and cmake. Problems occur in the docs stage. The last part of the rpmbuild log, leading up to the first reported problem, is attached. I'll provide the full rpmbuild log if needed, but thought this may be sufficient to provide clues. The rpmbuild spec file is unchanged from that used to successfully build 1488:882d3ccba621. To manage notifications about this bug go to: https://bugs.launchpad.net/enblend/+bug/1647215/+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 1647215] Re: Problems building current default
WOMS. Probably your LaTeX build chain is different. I have just checked my local Enblend/Enfuse repo on a Debian system and it builds the complete documentation. My prime suspect would be your "epstopdf.pl" or any driver program that fires it up. The docu build process is quite complicated. -- You received this bug notification because you are a member of Hugin Developers, which is subscribed to Enblend. https://bugs.launchpad.net/bugs/1647215 Title: Problems building current default Status in Enblend: New Bug description: Attempting to build the current default (1491:24c37812cde3) on Fedora 25 x86_64, using rpmbuild and cmake. Problems occur in the docs stage. The last part of the rpmbuild log, leading up to the first reported problem, is attached. I'll provide the full rpmbuild log if needed, but thought this may be sufficient to provide clues. The rpmbuild spec file is unchanged from that used to successfully build 1488:882d3ccba621. To manage notifications about this bug go to: https://bugs.launchpad.net/enblend/+bug/1647215/+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 1633354] Re: "enblend: warning: unable to run Dijkstra optimizer" for large panorama
> When running enblend with --visualize and path debugging, the program
> crashes. The effect is stat output suddenly stops, ...
It is possible that `--parameter=debug-path' does not jibe
well with OMP. (Any `--parameter' lets you rummage in the guts of
Enblend or Enfuse.) Try a non-OMP version or set `OMP_NUM_THREADS=1',
though neither trick may cut it.
> Maybe there is some LZW issue, because for the same image sometimes an
> LZW warning ("enblend: error: Deflate compression support is not
> configured") appears ...
This error is related to your TIFF library, which ought to fall
back to `no compression' in such a case.
> Still with different dijkstra parameters there is always a severe
> artefact in the resulting image.
Which is what I have suspected in #1: "The warning [of the
Dijkstra optimizer] is benign."
--
You received this bug notification because you are a member of Hugin
Developers, which is subscribed to Enblend.
https://bugs.launchpad.net/bugs/1633354
Title:
"enblend: warning: unable to run Dijkstra optimizer" for large
panorama
Status in Enblend:
Opinion
Bug description:
Reported for Hugin on Windows (32-bit version of Hugin):
https://bugs.launchpad.net/hugin/+bug/1633352
I suspect it's an enblend bug. I'm no expert on enblend, so I could use some
help how to diagnose, isolate and fix the problem.
To manage notifications about this bug go to:
https://bugs.launchpad.net/enblend/+bug/1633354/+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 1633354] Re: "enblend: warning: unable to run Dijkstra optimizer" for large panorama
The warning is benign. It is not related to the size of a panorama, but to the location of the tentative seam-line after Simulated Annealing. Use `--visualize' to check if there is a connection between the seam line and the supposed artifacts. For a more detailed look at the optimizer's job try `--parameter=debug-path'. You will want to divert this output to a log-file. Probably any of the optimizers' (S/A and Dijkstra) parameters that can be set at the Enblend commandline may influence the occurrence of the warning. So, you could run some experiments along this line, too. If you really want to jump into the source, "postoptimizer.h" and "path.h" are your starting points. Though I doubt whether one can improve on the situation, I'll be happy to accept your patches. TIA! ** Changed in: enblend Status: New => Opinion ** Changed in: enblend Importance: Undecided => Wishlist -- You received this bug notification because you are a member of Hugin Developers, which is subscribed to Enblend. https://bugs.launchpad.net/bugs/1633354 Title: "enblend: warning: unable to run Dijkstra optimizer" for large panorama Status in Enblend: Opinion Bug description: Reported for Hugin on Windows (32-bit version of Hugin): https://bugs.launchpad.net/hugin/+bug/1633352 I suspect it's an enblend bug. I'm no expert on enblend, so I could use some help how to diagnose, isolate and fix the problem. To manage notifications about this bug go to: https://bugs.launchpad.net/enblend/+bug/1633354/+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 1598583] Re: Missing image parts with graphcut seam generator
** Changed in: enblend Assignee: (unassigned) => Mikolaj Leszczynski (rosomack) -- You received this bug notification because you are a member of Hugin Developers, which is subscribed to Enblend. https://bugs.launchpad.net/bugs/1598583 Title: Missing image parts with graphcut seam generator Status in Enblend: New Bug description: In certain situations, enblend seems to just completely skip an image. So far it has only happend with an image on the bottom edge of the panorama, but who knows... Messing around with the crop, resolution and what images to include changes the behavior, so it seems kind of random. Happens both with multithreading and a single thread. This only happens in enblend 4.2, going back to 4.1.5 fixes the problem. Not sure whether the fault is in Hugin (bad or out of date command line) or in enblend. Here is a zip file with files needed to reproduce the bug (I hope): http://ajpanton.se/hugin_enblend_bugreport.zip I've removed as many input files as possible to make it smaller and faster to process. That's why there's so much empty space in the output. Steps to reproduce: 1a. Have Windows (tested on Windows 10, 64-bit). 1b. Have enblend 4.2 (tested both with the "official" build and the one included in 2016.2 beta, both x64). 1c. Have Hugin (testeed with 2015.0 and 2016.2 beta, both x64) with default settings. 2. Open the .pto file with Hugin. 3. Stitch. The output will look like "output 4.2.JPG", with one input image missing. enblend 4.1.5 does it correctly in "output 4.1.5.JPG" To manage notifications about this bug go to: https://bugs.launchpad.net/enblend/+bug/1598583/+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 1581889] Re: Current default branch fails to build
Commit a1fbf734e58a by Thomas gets the CMake system in lockstep with Autoconf/Automake again. WOMS. @Terry: THX for venturing out so far. ** Changed in: enblend Status: New => Fix Committed ** Changed in: enblend Importance: Undecided => High -- You received this bug notification because you are a member of Hugin Developers, which is subscribed to Enblend. https://bugs.launchpad.net/bugs/1581889 Title: Current default branch fails to build Status in Enblend: Fix Committed Bug description: Attempting to build the current default branch (1165d8692e19 1457 default) on Fedora 23 x86_64 using rpmbuild, the build exits with the following error message... In file included from /home/terry/rpmbuild/BUILD/enblend-4.3.0-1457hg-Source/src/enblend.cc:81:0: /home/terry/rpmbuild/BUILD/enblend-4.3.0-1457hg-Source/src/optional_transitional.hpp:56:2: error: #error "no viable, C++-17-compatible header file defined" #error "no viable, C++-17-compatible header file defined" Have I missed something that is required, or ?? Cheers, Terry To manage notifications about this bug go to: https://bugs.launchpad.net/enblend/+bug/1581889/+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 1581889] Re: Current default branch fails to build
Only the Autoconf/Automake side of configuration is supposed to work right now. http://hg.code.sf.net/p/enblend/code/rev/062ef888f4cf If you happened to configure with CMake the breakage is expected. Surely Thomas will adjust the CMake side as always. -- You received this bug notification because you are a member of Hugin Developers, which is subscribed to Enblend. https://bugs.launchpad.net/bugs/1581889 Title: Current default branch fails to build Status in Enblend: New Bug description: Attempting to build the current default branch (1165d8692e19 1457 default) on Fedora 23 x86_64 using rpmbuild, the build exits with the following error message... In file included from /home/terry/rpmbuild/BUILD/enblend-4.3.0-1457hg-Source/src/enblend.cc:81:0: /home/terry/rpmbuild/BUILD/enblend-4.3.0-1457hg-Source/src/optional_transitional.hpp:56:2: error: #error "no viable, C++-17-compatible header file defined" #error "no viable, C++-17-compatible header file defined" Have I missed something that is required, or ?? Cheers, Terry To manage notifications about this bug go to: https://bugs.launchpad.net/enblend/+bug/1581889/+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 1576862] Re: Artefacts after enfuse
If using option `--no-ciecam' or future-proof option
`--blend-colorspace=identity' fixes the problem this
report is a duplicate of #752283.
--
You received this bug notification because you are a member of Hugin
Developers, which is subscribed to Enblend.
https://bugs.launchpad.net/bugs/1576862
Title:
Artefacts after enfuse
Status in Enblend:
New
Bug description:
Source files: http://fliker09.tk:8800/Source.zip
Result: http://fliker09.tk:8800/Enfused.tiff
WARNING! Big files.
Command: enfuse --depth=16 -o Enfused.tif {1..7}.tiff
These color pixels drives me crazy, I can't understand why they appear...
If additional information required just ask!
To manage notifications about this bug go to:
https://bugs.launchpad.net/enblend/+bug/1576862/+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 1568917] Re: enblend 4.2 CMake error
Probably fixed in rev 1f276a9e5840. ** Changed in: enblend Status: New => Fix Committed ** Changed in: enblend Importance: Undecided => Low -- You received this bug notification because you are a member of Hugin Developers, which is subscribed to Enblend. https://bugs.launchpad.net/bugs/1568917 Title: enblend 4.2 CMake error Status in Enblend: Fix Committed Bug description: I run into the following problem failing to configure/build enblend- enfuse 4.2 using the CMake build system. [...] -- Boost_FOUND = 1 -- OpenMP_CXX_FLAGS = -fopenmp -- Adding PROPERTIES LINK_FLAGS to enblend and enfuse CMake Error at src/CMakeLists.txt:77 (add_subdirectory): The source directory /var/tmp/paludis/build/media-gfx-enblend-enfuse-4.2/work/enblend- enfuse-4.2/src/layer_selection does not contain a CMakeLists.txt file. CMake Error at src/CMakeLists.txt:81 (add_subdirectory): The source directory /var/tmp/paludis/build/media-gfx-enblend-enfuse-4.2/work/enblend- enfuse-4.2/src/dynamic_loader does not contain a CMakeLists.txt file. Attached is a full build.log To manage notifications about this bug go to: https://bugs.launchpad.net/enblend/+bug/1568917/+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 1565269] Re: enblend 4.2 build error without latex
Should be fixed in rev 78a09bc743b7, which will be backported to 4.2.1.
Given the complexity and sheer mass of checks for the documentation,
I expect more bugs to show up time after time.
** Changed in: enblend
Assignee: (unassigned) => Christoph Spiel (cspiel)
** Changed in: enblend
Status: New => Fix Committed
** Changed in: enblend
Importance: Undecided => Medium
--
You received this bug notification because you are a member of Hugin
Developers, which is subscribed to Enblend.
https://bugs.launchpad.net/bugs/1565269
Title:
enblend 4.2 build error without latex
Status in Enblend:
Fix Committed
Bug description:
enblend 4.2 has a hard dependency on (pdf)latex:
checking for perl module Time::Zone... ok
checking for latex... no
checking for elatex... no
checking for lambda... no
../configure: line 8623: WARNING:: command not found
checking for pdflatex... ../configure: line 8655: WARNING:: command not found
no
checking for latex... no
checking for elatex... no
checking for lambda... no
configure: error: Unable to find a LaTeX application
Afaict this code in configure.ac fails to work as expected:
---
can_build_doc=yes
AC_PATH_PROGS(LATEX, [latex elatex lambda],
[AC_MSG_WARN(missing LaTeX translator)
can_build_doc=no
missing_for_doc="$missing_for_doc latex"])
AC_PATH_PROG(PDFLATEX, pdflatex,
[AC_MSG_WARN([missing PDFLaTeX translator -- no direct
translation of LaTeX to PDF available])
missing_for_doc="$missing_for_doc pdflatex"])
if test "$latex" != 'no'
then
AC_LATEX_CLASS(report,report,[],
[AC_MSG_WARN(missing document class report.cls)
can_build_doc=no
missing_for_doc="$missing_for_doc report.cls"])
-
AC_PATH_PROGS would set $LATEX ("upper case") on success and
can_build_doc=no otherwise but the code checks "$latex" != 'no' instead of
'"$can_build_doc'='yes'. Therefore AC_LATEX_CLASS is always invoked which
afaict invokes AC_PROG_LATEX and throws a hard error of AC_PROG_LATE fails.
cu Andreas
To manage notifications about this bug go to:
https://bugs.launchpad.net/enblend/+bug/1565269/+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 1469004] Re: Problems building 4.2 docs
Fixed in 4.2. ** Changed in: enblend Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Hugin Developers, which is subscribed to Enblend. https://bugs.launchpad.net/bugs/1469004 Title: Problems building 4.2 docs Status in Enblend: Fix Released Bug description: Running into problems generating the pdf docs, on Fedora 21 if I run ./configure, it reports "can build all documentation: yes" Building in rpmbuild using cmake, with -DDOC=ON, ps docs are generated OK. Building in rpmbuild using cmake, with -DDOC=ON -DINSTALL_HTML_DOC=ON, both ps and html docs are generated. Building in rpmbuild using cmake, with -DDOC=ON -DINSTALL_PDF_DOC=ON, my build fails with following info; [ 35%] Generating fullsine.pstex cd /home/terry/rpmbuild/BUILD/enblend-4.2.0-1180hg-Source/doc && /usr/bin/gnuplot --default-settings -e 'DATA_DIR="/home/terry/rpmbuild/BUILD/enblend-4.2.0-1180hg-Source/doc"' -e set\ output\ \"fullsine.tex\"\;\ set\ terminal\ epslatex\ /home/terry/rpmbuild/BUILD/enblend-4.2.0-1180hg-Source/doc/fullsine.gp Error renaming from "exposure-weights.tex" to "exposure-weights.pstex": No such file or directory doc/CMakeFiles/pdf.dir/build.make:351: recipe for target 'doc/exposure-weights.pstex' failed make[2]: *** [doc/exposure-weights.pstex] Error 1 I also note that the ps and html docs are not the same. The ps contains a list of tables, html does not. I note a minor a mistake in the ps 'list of tables', page 46, "Visualization colors an symbols...", suspect this should be "Visualization colors and symbols". Cheers, Terry To manage notifications about this bug go to: https://bugs.launchpad.net/enblend/+bug/1469004/+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] Re: DVI output fails on SMP build
Fixed in 4.2. ** Changed in: enblend Status: Fix Committed => Fix Released -- 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 Released 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 1181678] Re: build-error with texinfo 5.1
Fixed in 4.1.4. Version 4.2 does not use Texinfo, so the problem does not occur. ** Changed in: enblend Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Hugin Developers, which is subscribed to Enblend. https://bugs.launchpad.net/bugs/1181678 Title: build-error with texinfo 5.1 Status in Enblend: Fix Released Status in enblend package in Gentoo Linux: Unknown Bug description: Hello, documentation generation fails with texinfo 5.1. texinfo seems to have stopped supporting colons in variable names (@set <-> @value), causing errors like this one: - doc/enfuse.texi:564: bad syntax for @value - According to texinfo 5.1 documentation basically the only thing guaranteed to work are alpha-numericals: Subsequent characters, if any, may not be whitespace, ‘@’, braces, angle brackets, or any of ‘~`^+|’; other characters, such as ‘%’, may work. However, it is best to use only letters and numerals in a flag name, not ‘-’ or ‘_’ or others—they will work in some contexts, but not all, due to limitations in TeX. cu Andreas See http://bugs.debian.org/708800 or https://bugzilla.redhat.com/show_bug.cgi?id=919935 To manage notifications about this bug go to: https://bugs.launchpad.net/enblend/+bug/1181678/+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 746653] Re: FR: 2 Mu parameters instead of 1 (enfuse)
Fixed in 4.2. ** Changed in: enblend Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Hugin Developers, which is subscribed to Enblend. https://bugs.launchpad.net/bugs/746653 Title: FR: 2 Mu parameters instead of 1 (enfuse) Status in Enblend: Fix Released Bug description: I hope I have understood the parameters right, but the Mu parameter represents the middle gamma value of the enfusion (defining the middle "grey" basically). Would it be possible to introduce Mu1 and Mu2, which by default would be 0.33 and 0.66. The two values would basically control the relative brightness of the shadows and highlights, giving the user an opportunity to selectively bring in more highlight details and/or shadow details during the enfusion process... the old Mu would be defined as the center between Mu1 and Mu2. To manage notifications about this bug go to: https://bugs.launchpad.net/enblend/+bug/746653/+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 1332323] Re: Fix issues reported by valgrind
Fixed in 4.1.4 and 4.2. ** Changed in: enblend Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Hugin Developers, which is subscribed to Enblend. https://bugs.launchpad.net/bugs/1332323 Title: Fix issues reported by valgrind Status in Enblend: Fix Released Bug description: Hi everyone, I ran enblend under valgrind which reported several issues. The first one is a simple missing initialization. The other ones are mostly about bad usage of boost::scoped_ptr<>. I have two different approaches to fix this: 1. Directly write into std::string buffer instead of using a temporary char[] buffer. This is guaranteed behavior by C++11, see e.g. http://herbsutter.com/2008/04/07/cringe-not-vectors-are-guaranteed-to-be-contiguous/#comment-483 2. Use a boost::tokenizer. As it does not need a char[] buffer, different to strtok, no need to allocate one. This has the nice side effect to get rid of the homegrown enblend::strtoken_r tokenizer. Kind regards, Stefan To manage notifications about this bug go to: https://bugs.launchpad.net/enblend/+bug/1332323/+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 1256621] Re: compilation fails since introduction of timer
Fixed in 4.2. ** Changed in: enblend Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Hugin Developers, which is subscribed to Enblend. https://bugs.launchpad.net/bugs/1256621 Title: compilation fails since introduction of timer Status in Enblend: Fix Released Bug description: Hi, Since the introduction of the timer class (around changeset 981) I get compile time errors about non existing types. Is that a missing 'include' or am I missing some flag? cheers, lukas [ 3%] Building CXX object src/CMakeFiles/enblend.dir/timer.cc.o In file included from /usr/src/pano/enblend_hg/src/timer.cc:22:0: /usr/src/pano/enblend_hg/src/timer.h:121:9: error: ‘tms’ does not name a type /usr/src/pano/enblend_hg/src/timer.h:122:9: error: ‘tms’ does not name a type /usr/src/pano/enblend_hg/src/timer.cc: In member function ‘void timer::ProcessorTime::start()’: /usr/src/pano/enblend_hg/src/timer.cc:135:16: error: ‘start_’ was not declared in this scope /usr/src/pano/enblend_hg/src/timer.cc:135:22: error: ‘times’ was not declared in this scope /usr/src/pano/enblend_hg/src/timer.cc:136:9: error: ‘stop_’ was not declared in this scope /usr/src/pano/enblend_hg/src/timer.cc: In member function ‘void timer::ProcessorTime::stop()’: /usr/src/pano/enblend_hg/src/timer.cc:144:16: error: ‘stop_’ was not declared in this scope /usr/src/pano/enblend_hg/src/timer.cc:144:21: error: ‘times’ was not declared in this scope /usr/src/pano/enblend_hg/src/timer.cc:145:41: error: ‘start_’ was not declared in this scope /usr/src/pano/enblend_hg/src/timer.cc: In member function ‘void timer::ProcessorTime::restart()’: /usr/src/pano/enblend_hg/src/timer.cc:155:16: error: ‘start_’ was not declared in this scope /usr/src/pano/enblend_hg/src/timer.cc:155:22: error: ‘times’ was not declared in this scope /usr/src/pano/enblend_hg/src/timer.cc:156:9: error: ‘stop_’ was not declared in this scope make[2]: *** [src/CMakeFiles/enblend.dir/timer.cc.o] Error 1 make[1]: *** [src/CMakeFiles/enblend.dir/all] Error 2 make: *** [all] Error 2 To manage notifications about this bug go to: https://bugs.launchpad.net/enblend/+bug/1256621/+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] Re: convert -3 error building docs
** Changed in: enblend Status: Fix Committed => Fix Released -- 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: Fix Released 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 1356551] Re: White pixels at 180 wrap and zenith for 16/32bit HDR Pano
Fixed in 4.2. ** Changed in: enblend Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Hugin Developers, which is subscribed to Enblend. https://bugs.launchpad.net/bugs/1356551 Title: White pixels at 180 wrap and zenith for 16/32bit HDR Pano Status in Enblend: Fix Released Status in Hugin: Invalid Bug description: When stitching my final pano for an HDR workflow I get a column of blank/white pixels near the equator at the 180 wrap and an entire row of blank/white pixels at the top. Here's the basic pieces of my workflow: - Multiple exposures at 7 angles with samyang 8mm + pano head - Combined exposures to 7 HDR images using pfstools (sometimes exr files for 16bpp, other times tiff for 32bpp) - Use hugin to: mask out pano head arm, find control points, optimize positions, barrel and view and set output options - Stitch with a script using nona+enblend to equirec HDR image Can view example of the white pixels here: - you're facing the 180 wrap when it first comes up - zoom in at zenith to see the missing top pixel http://vr.rollerblading.es/pano/file?path=https://dl.dropboxusercontent.com/u/3340541/Panos/MuralLobby-Pano-LDR.jpg When I look at intermediate files I'm pretty sure it is enblend that is the source of the problem. I've tried several different versions: - The stock version from the OSX binary on the source forge web site (v 4.1.1) - Enblend 4.1.2_2 compiled with macports - Enblend 4.1.3 compiled with macports (using my own updated portfile to grab the 4.1.3 tar ball) All three versions show the same problem. I'll attach a screenshot pointing out the truant pixels as well as a minimal .pto file and the script I use for stitching. To manage notifications about this bug go to: https://bugs.launchpad.net/enblend/+bug/1356551/+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 1374686] Re: Enblend adds black to edges of some pictures in a pano sometimes when using include masks.
Fixed in 4.2. ** Changed in: enblend Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Hugin Developers, which is subscribed to Enblend. https://bugs.launchpad.net/bugs/1374686 Title: Enblend adds black to edges of some pictures in a pano sometimes when using include masks. Status in Enblend: Fix Released Bug description: Here are two examples http://kvtours.com/test-photos/CraterLake.jpg and http://kvtours.com/test-photos/Wheeler1.jpg http://kvtours.com/test-photos/enblendBlackEdgeErrorTest.zip That is a 8.12mb test package for use with hugin. The test package is an example that I just took out of a half pano that I was working on last nightt, that I doubt many people would have cause to do, but it was an easy one to show the problem with. In it you will find two pictures and a pto file. One of the pictures is in the pto file twice. The second copy has different light settings so that the sun is not quite so blown out. There is complete overlap on those two images. When I put a single include mask on the one that has a good sun I get a pretty good result, but the mask goes a bit further away from the sun than I want. So I add a second include mask to the other copy to keep most of the good colors and then I get the results shown in the Wheeler1.jpg If I remove one of the include masks and instead use one include and one exclude I get the results that I want with no bugs. Remove both masks it works as expected as well. On the crater lake one I did it a month ago and it more clearly shows the problem(I did not include it as a test package as it is a large set). My work flow on it, I was going along stitching small versions finding places where there were masking errors or that I needed more control points and correcting as I saw fit and then somewhere along the lines the black started showing up. At first it was just a little bit on the rock under the tri-pod. That caught my eye and I removed all the masks in that area and restitched. That did not remove the problem(I still had masks in other places.) I figured I could photoshop it so I continued and a few masks and restitches later I had problems showing up in places where there were and had never been a mask(that is the photo that I attached to this post). At that point I scrapped the project and started over and had no problems on my second try. I have seen the bug with both the version of enblend that comes with hugin 2013 and enblend 4.1.3 win64 version. I am running windows 7 on a desktop. A friend has had the same problems with windows 7 on a laptop. For command line options I use the standard that hugin has plus I add in -a --no-ciecam Here is the thread where I first started talking about it. https://groups.google.com/forum/#!msg/hugin-ptx/pQYSIjk7Af8/WyYBRSz_CgMJ To manage notifications about this bug go to: https://bugs.launchpad.net/enblend/+bug/1374686/+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 1157155] Re: enblend 4.1 generates brighter images than originals
Fixed in 4.2. ** Changed in: enblend Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Hugin Developers, which is subscribed to Enblend. https://bugs.launchpad.net/bugs/1157155 Title: enblend 4.1 generates brighter images than originals Status in Enblend: Fix Released Bug description: I just notice that the recent versions of enblend (4.1 I think) generates a panorama image which is much more brighter than the original JPEGs. When the original JPEGs contain some black or dark areas, they becomes grey (like a problem of gamma). I check with Gimp and the histogram no longer contains black or dark colors as if it was compressed at right. As I didn't remember this kind of problems with previous enblend versions, I looked in recent options like CIECAM02 which is enabled by default. And, when I use --no-ciecam, the problem disappears. (In my case, all my original JPEGs are in sRGB and for this test case, I haven't done any exposition correction in Hugin : I just compare the result by adding and removing --no-ciecam). So, is it a regression or an expected behaviour ? To manage notifications about this bug go to: https://bugs.launchpad.net/enblend/+bug/1157155/+subscriptions ___ Mailing list: https://launchpad.net/~hugin-devs Post to : hugin-devs@lists.launchpad.net Unsubscribe : https://launchpad.net/~hugin-devs More help : https://help.launchpad.net/ListHelp
[Hugin-devs] [Bug 685105] Re: enblend fails to blend large pano
** Changed in: enblend Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Hugin Developers, which is subscribed to Enblend. https://bugs.launchpad.net/bugs/685105 Title: enblend fails to blend large pano Status in Enblend: Fix Released Bug description: Enblend failed with: enblend --compression=LZW -m 1200 -w -f135659x3947+0+1091 -o pano8110_l.tif ... enblend: info: loading next image: pano8110_l.tif 1/1 enblend: out of memory enblend: std::bad_alloc This is a simple 0.5Gpixel panorama I shot. And agreed, Hugin did warn me that it might take a lot of memory. The thing is: There is no other tool to stitch this with, so I'll have to make do with hugin and its toolset I thought there was an "imagecache" that would swap parts of images to disk... To manage notifications about this bug go to: https://bugs.launchpad.net/enblend/+bug/685105/+subscriptions ___ Mailing list: https://launchpad.net/~hugin-devs Post to : hugin-devs@lists.launchpad.net Unsubscribe : https://launchpad.net/~hugin-devs More help : https://help.launchpad.net/ListHelp
[Hugin-devs] [Bug 1537368] Re: enblend 4.1.4 build-error with gcc-6
Released version 4.1 Patchlevel 5: http://hg.code.sf.net/p/enblend/code/file/f8a34cfab8c1/NEWS ** Changed in: enblend Status: In Progress => Fix Released -- You received this bug notification because you are a member of Hugin Developers, which is subscribed to Enblend. https://bugs.launchpad.net/bugs/1537368 Title: enblend 4.1.4 build-error with gcc-6 Status in Enblend: Fix Released Bug description: Hello, enblend 4.1.4 FTBFS with gcc/g++ 6 (tested with snapshot 20160117): ../../include/vigra_ext/impexalpha.hxx:252:78: error: no matching function for call to 'std::auto_ptr::auto_ptr(std::unique_ptr)' std::auto_ptr decoder(vigra::decoder(import_info)); ^ This does not apply to HG default! See https://bugs.debian.org/811869 and https://wiki.debian.org/GCC6 cu Andreas To manage notifications about this bug go to: https://bugs.launchpad.net/enblend/+bug/1537368/+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 1537368] Re: enblend 4.1.4 build-error with gcc-6
Wrt to #5: No gcc-6 here, so dunno. Andreas would have hollered, though. -- You received this bug notification because you are a member of Hugin Developers, which is subscribed to Enblend. https://bugs.launchpad.net/bugs/1537368 Title: enblend 4.1.4 build-error with gcc-6 Status in Enblend: In Progress Bug description: Hello, enblend 4.1.4 FTBFS with gcc/g++ 6 (tested with snapshot 20160117): ../../include/vigra_ext/impexalpha.hxx:252:78: error: no matching function for call to 'std::auto_ptr::auto_ptr(std::unique_ptr)' std::auto_ptr decoder(vigra::decoder(import_info)); ^ This does not apply to HG default! See https://bugs.debian.org/811869 and https://wiki.debian.org/GCC6 cu Andreas To manage notifications about this bug go to: https://bugs.launchpad.net/enblend/+bug/1537368/+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 1537368] Re: enblend 4.1.4 build-error with gcc-6
Broken compilation with gcc-6 as reported in #2 should be fixed in rev 73e6f16de80a. Dropped the dependency on `boost::assign' at the offending position; it did not buy us that much anyhow. -- You received this bug notification because you are a member of Hugin Developers, which is subscribed to Enblend. https://bugs.launchpad.net/bugs/1537368 Title: enblend 4.1.4 build-error with gcc-6 Status in Enblend: In Progress Bug description: Hello, enblend 4.1.4 FTBFS with gcc/g++ 6 (tested with snapshot 20160117): ../../include/vigra_ext/impexalpha.hxx:252:78: error: no matching function for call to 'std::auto_ptr::auto_ptr(std::unique_ptr)' std::auto_ptr decoder(vigra::decoder(import_info)); ^ This does not apply to HG default! See https://bugs.debian.org/811869 and https://wiki.debian.org/GCC6 cu Andreas To manage notifications about this bug go to: https://bugs.launchpad.net/enblend/+bug/1537368/+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 1537368] Re: enblend 4.1.4 build-error with gcc-6
** Changed in: enblend Status: Fix Committed => In Progress -- You received this bug notification because you are a member of Hugin Developers, which is subscribed to Enblend. https://bugs.launchpad.net/bugs/1537368 Title: enblend 4.1.4 build-error with gcc-6 Status in Enblend: In Progress Bug description: Hello, enblend 4.1.4 FTBFS with gcc/g++ 6 (tested with snapshot 20160117): ../../include/vigra_ext/impexalpha.hxx:252:78: error: no matching function for call to 'std::auto_ptr::auto_ptr(std::unique_ptr)' std::auto_ptr decoder(vigra::decoder(import_info)); ^ This does not apply to HG default! See https://bugs.debian.org/811869 and https://wiki.debian.org/GCC6 cu Andreas To manage notifications about this bug go to: https://bugs.launchpad.net/enblend/+bug/1537368/+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 1537368] Re: enblend 4.1.4 build-error with gcc-6
** Changed in: enblend Status: New => In Progress ** Changed in: enblend Importance: Undecided => Medium ** Changed in: enblend Assignee: (unassigned) => Christoph Spiel (cspiel) -- You received this bug notification because you are a member of Hugin Developers, which is subscribed to Enblend. https://bugs.launchpad.net/bugs/1537368 Title: enblend 4.1.4 build-error with gcc-6 Status in Enblend: In Progress Bug description: Hello, enblend 4.1.4 FTBFS with gcc/g++ 6 (tested with snapshot 20160117): ../../include/vigra_ext/impexalpha.hxx:252:78: error: no matching function for call to 'std::auto_ptr::auto_ptr(std::unique_ptr)' std::auto_ptr decoder(vigra::decoder(import_info)); ^ This does not apply to HG default! See https://bugs.debian.org/811869 and https://wiki.debian.org/GCC6 cu Andreas To manage notifications about this bug go to: https://bugs.launchpad.net/enblend/+bug/1537368/+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 1537368] Re: enblend 4.1.4 build-error with gcc-6
Fixed in rev 467a73754dbb. I had to open up `Patchlevel 5', which is _unreleased_ and which will remain open for a while in case gcc-6 finds more problems. That way you can carry on testing/porting. > This does not apply to HG default! The offending source does not exist in the current tip of the `Development Branch'. All local changes to Vigra were pushed to the Vigra-project a long time ago. ** Changed in: enblend Status: In Progress => Fix Committed -- You received this bug notification because you are a member of Hugin Developers, which is subscribed to Enblend. https://bugs.launchpad.net/bugs/1537368 Title: enblend 4.1.4 build-error with gcc-6 Status in Enblend: Fix Committed Bug description: Hello, enblend 4.1.4 FTBFS with gcc/g++ 6 (tested with snapshot 20160117): ../../include/vigra_ext/impexalpha.hxx:252:78: error: no matching function for call to 'std::auto_ptr::auto_ptr(std::unique_ptr)' std::auto_ptr decoder(vigra::decoder(import_info)); ^ This does not apply to HG default! See https://bugs.debian.org/811869 and https://wiki.debian.org/GCC6 cu Andreas To manage notifications about this bug go to: https://bugs.launchpad.net/enblend/+bug/1537368/+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 1181678] Re: build-error with texinfo 5.1
Made to work again in the Stable Branch in rev 8387f0170f7b: http://hg.code.sf.net/p/enblend/code/rev/8387f0170f7b Thus, the problem will be solved in the next patch-level, i.e. version 4.1.4. The issue does not apply to Development Branch because Texinfo as source of the documentation was replaced with pure LaTeX. ** Changed in: enblend Status: Triaged = Fix Committed ** Changed in: enblend Assignee: (unassigned) = Christoph Spiel (cspiel) -- You received this bug notification because you are a member of Hugin Developers, which is subscribed to Enblend. https://bugs.launchpad.net/bugs/1181678 Title: build-error with texinfo 5.1 Status in Enblend: Fix Committed Status in enblend package in Gentoo Linux: Unknown Bug description: Hello, documentation generation fails with texinfo 5.1. texinfo seems to have stopped supporting colons in variable names (@set - @value), causing errors like this one: - doc/enfuse.texi:564: bad syntax for @value - According to texinfo 5.1 documentation basically the only thing guaranteed to work are alpha-numericals: Subsequent characters, if any, may not be whitespace, ‘@’, braces, angle brackets, or any of ‘~`^+|’; other characters, such as ‘%’, may work. However, it is best to use only letters and numerals in a flag name, not ‘-’ or ‘_’ or others—they will work in some contexts, but not all, due to limitations in TeX. cu Andreas See http://bugs.debian.org/708800 or https://bugzilla.redhat.com/show_bug.cgi?id=919935 To manage notifications about this bug go to: https://bugs.launchpad.net/enblend/+bug/1181678/+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] Re: DVI output fails on SMP build
Fixed in ef895497dff3. ** Changed in: enblend Status: New = Fix Committed -- 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 1468520] Re: make dist fails
I'll postpone the patch #5 indefinitely and
put this issue into state won't fix. The less
we molest Automake the better.
@Bruno: Please reopen and apply a fix à ton goût if
you have a brilliant idea.
** Changed in: enblend
Status: Incomplete = Won't Fix
--
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:
Won't Fix
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
I understand that `make dist' fails. As automake(1) sets up our Makefiles
it _must_ fail after a `make clean'.
Check whether the patch in #5 fixes the problem. If it does I still would
be hesitant to apply it until we get the blessings from some of the
Autoconf/Automake demi-gods.
--
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
Patch rename-share-gnumakefile.diff went into rev 8f3ccaa707e6:
http://hg.code.sf.net/p/enblend/code/rev/8f3ccaa707e6
So this part is patch applied.
I set the issue's status to incomplete until you find out whether
the `dist'-target depends on `all'. See comment #3.
** Changed in: enblend
Status: Confirmed = Incomplete
--
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
Actually, #2 is a new and different problem. We do want to support
in-place builds, but make(1) is just overzealous and [ab]uses
GNUmakefile in share/enfuse, which is to be shipped for the
convenience of our users, not for building any part of the
Enblend/Enfuse project. The attached patch
rename-share-gnumakefile.diff should fix that. Please try!
As for the original problem, `dist' not working unless preceded by
`all'. I don't know the exact intended semantics of the
`dist'-target. It surely is debatable whether `all' is necessary
before `dist' or the `dist'-target takes care of everything even if we
start from `clean'. What do the Automake gurus say? A fix is
trivial, see override-dist-target-dependence.diff.
--
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:
Confirmed
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
** Patch added: rename-share-gnumakefile.diff
https://bugs.launchpad.net/enblend/+bug/1468520/+attachment/4421969/+files/rename-share-gnumakefile.diff
--
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:
Confirmed
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
** Patch added: override-dist-target-dependence.diff
https://bugs.launchpad.net/enblend/+bug/1468520/+attachment/4421970/+files/override-dist-target-dependence.diff
** Changed in: enblend
Status: New = Confirmed
--
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:
Confirmed
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
Your exact problem as demonstrated by your
transcript is not reproducible on my machine.
However, `make dist' fails for me, too when
called right after a `make clean'. OTOH, `make
dist' always succeeds after a `make all' or just
`make'.
It seems as if the order in which the
sub-directories are built is different and wrong
with the `dist' target, whereas it works
correctly and in particular as advertised in the
Automake documentation
https://www.gnu.org/software/automake/manual/automake.html#Subdirectories
when using targets like e.g. `all'.
$ automake --version
automake (GNU automake) 1.14.1
$ autoconf --version
autoconf (GNU Autoconf) 2.69
** Changed in: enblend
Importance: Undecided = Medium
** Changed in: enblend
Assignee: (unassigned) = Christoph Spiel (cspiel)
--
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] Re: convert -3 error building docs
Should be fixed in rev 0c051e944b27. We no longer use tiff2ps(1) at all. The job gets done by convert(1). Thus, there is no TIFF2PS_FLAGS anymore. ** Changed in: enblend Status: New = Fix Committed ** Changed in: enblend Importance: Undecided = Medium ** Changed in: enblend Assignee: (unassigned) = Christoph Spiel (cspiel) -- 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: Fix Committed 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 1460928] Re: Current repo src gives bad blend with masks
Thanks Terry for reporting the problem. It is reproducible. The source of the problems isn't the masks though, it is the topology of the resulting input images (to Enblend). Sure, exactly the mask-feature makes creating such a topology so easy. Requesting the seam-line visualizations (`--visualize') tells you that the algorithms have gone banana cuckoo. I'm surprised that you didn't come up with a trivial solution of the problem, namely dumbing down Enblend (almost) to the level of Verdandi: --primary-seam-generator=nft --fine-mask --no-optimize With these extra options the seam-lines behave and the output looks quite reasonable. ** Changed in: enblend Status: New = Confirmed -- You received this bug notification because you are a member of Hugin Developers, which is subscribed to Enblend. https://bugs.launchpad.net/bugs/1460928 Title: Current repo src gives bad blend with masks Status in Enblend: Confirmed Bug description: A build of the current repository source (enblend-4.2.0-1165) gives a bad result when blending images with masks. The hugin builtin blender (verdandi) produces the expected result. Attached archive includes 4 project images, screenshot of stitches from enblend and verdandi, and a hugin project file. To manage notifications about this bug go to: https://bugs.launchpad.net/enblend/+bug/1460928/+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 1384674] Re: enblend running out of temp space: poor diagnostics and configuration possibilities
** Changed in: enblend Status: Triaged = Fix Committed -- You received this bug notification because you are a member of Hugin Developers, which is subscribed to Enblend. https://bugs.launchpad.net/bugs/1384674 Title: enblend running out of temp space: poor diagnostics and configuration possibilities Status in Enblend: Fix Committed Status in “hugin” package in Ubuntu: Invalid Bug description: Hi, this is mostly a duplicate of https://bugs.launchpad.net/enblend/+bug/1220523. I would like to add that the diagnostic messages and documentation could be a lot better in this situation. Instead of enblend: No space left on device it would be much more helpfull to say *which device/dricetory* as this does not appear documented anywhere. Furthermore, is this device hardcoded in the source code or is it configurable somewhere? Again, did not find anything in the documentation. Finally, this just happened to me with $ df /tmp/ Filesystem 1K-blocks Used Available Use% Mounted on tmpfs1028148 924 1027224 1% /tmp and trying to stitch together 31 images. It would seem that similar situations may become increasingly common in the near future. Regards To manage notifications about this bug go to: https://bugs.launchpad.net/enblend/+bug/1384674/+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 1374686] Re: Enblend adds black to edges of some pictures in a pano sometimes when using include masks.
Revision 8f4a08e6a317 should restore total correctness http://hg.code.sf.net/p/enblend/code/rev/8f4a08e6a317 Now, Enblend will abort if it encounters a near-overlap that its algorithm is not able to handle. We are not as strict as we could be, but most problems should be caught by the new check. However, the borders of the black alpha mask's are still untested. You can play with the check's threshold parameter to fit it to your images. Let us know, whether we ought to adapt the default. ** Changed in: enblend Status: New = Fix Committed ** Changed in: enblend Importance: Undecided = Medium ** Changed in: enblend Assignee: (unassigned) = Christoph Spiel (cspiel) -- You received this bug notification because you are a member of Hugin Developers, which is subscribed to Enblend. https://bugs.launchpad.net/bugs/1374686 Title: Enblend adds black to edges of some pictures in a pano sometimes when using include masks. Status in Enblend: Fix Committed Bug description: Here are two examples http://kvtours.com/test-photos/CraterLake.jpg and http://kvtours.com/test-photos/Wheeler1.jpg http://kvtours.com/test-photos/enblendBlackEdgeErrorTest.zip That is a 8.12mb test package for use with hugin. The test package is an example that I just took out of a half pano that I was working on last nightt, that I doubt many people would have cause to do, but it was an easy one to show the problem with. In it you will find two pictures and a pto file. One of the pictures is in the pto file twice. The second copy has different light settings so that the sun is not quite so blown out. There is complete overlap on those two images. When I put a single include mask on the one that has a good sun I get a pretty good result, but the mask goes a bit further away from the sun than I want. So I add a second include mask to the other copy to keep most of the good colors and then I get the results shown in the Wheeler1.jpg If I remove one of the include masks and instead use one include and one exclude I get the results that I want with no bugs. Remove both masks it works as expected as well. On the crater lake one I did it a month ago and it more clearly shows the problem(I did not include it as a test package as it is a large set). My work flow on it, I was going along stitching small versions finding places where there were masking errors or that I needed more control points and correcting as I saw fit and then somewhere along the lines the black started showing up. At first it was just a little bit on the rock under the tri-pod. That caught my eye and I removed all the masks in that area and restitched. That did not remove the problem(I still had masks in other places.) I figured I could photoshop it so I continued and a few masks and restitches later I had problems showing up in places where there were and had never been a mask(that is the photo that I attached to this post). At that point I scrapped the project and started over and had no problems on my second try. I have seen the bug with both the version of enblend that comes with hugin 2013 and enblend 4.1.3 win64 version. I am running windows 7 on a desktop. A friend has had the same problems with windows 7 on a laptop. For command line options I use the standard that hugin has plus I add in -a --no-ciecam Here is the thread where I first started talking about it. https://groups.google.com/forum/#!msg/hugin-ptx/pQYSIjk7Af8/WyYBRSz_CgMJ To manage notifications about this bug go to: https://bugs.launchpad.net/enblend/+bug/1374686/+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 1384674] Re: enblend running out of temp space: poor diagnostics and configuration possibilities
OK -- even at the danger of loosing focus let me try to explain each your points. enblend-4.1.1-3.fc19.i686 The latest release in the Stable Branch is 4.1.3. We are already preparing 4.1.4. OTOH, the Development Branch of course holds much more goodies. The TMPDIR ought also be mentioned in the manpage, attaching a patch. THX for your patch! We have a pretty similar one in rev188e286e471d, which I just back-ported to the Stable Branch. It will show up in 4.1.4. However, looking at the source code I am wondering if TMPDIR gets used at all - or is it dead code now? (i) Enblend and Enfuse only refer to the environment variable `TMPDIR' if they were compiled with the ImageCache feature. Otherwise they store everything in core and thus don't need a reference to a scratch directory. (ii) The ImageCache feature was withdrawn in 4.2 because of the spurious problems it causes; see, e.g. https://bugs.launchpad.net/enblend/+bug/807439 Moreover, the ImageCache is incompatible with OpenMP, our main parallelization technology. Therefore, current Development Branch does not use `TMPDIR', either. (iii) The `mmap_view' branch http://hg.code.sf.net/p/enblend/code/rev/7a3964af671a uses a different caching scheme to offload image data from core to disk. It needs to know where to store the backing-files for the images and thus again refers to `TMPDIR'. In my case I had additional screw up as hugin discarded the preset TMPDIR and when setting the hugin tmpdir via gui somehow this setting has been reset on one occasion. This looks more like a Hugin issue to me, although we can think about adding a command-line option to set/override `TMPDIR'. You could easily work around the problem by wrapping the calls to Enblend and Enfuse in shell scripts that override `TMPDIR'. I imagine something like #! /bin/dash export TMPDIR=/work exec /usr/local/bin/enblend $@ ** Changed in: enblend Status: New = Triaged ** Changed in: enblend Importance: Undecided = Medium ** Changed in: enblend Assignee: (unassigned) = Christoph Spiel (cspiel) -- You received this bug notification because you are a member of Hugin Developers, which is subscribed to Enblend. https://bugs.launchpad.net/bugs/1384674 Title: enblend running out of temp space: poor diagnostics and configuration possibilities Status in Enblend: Triaged Status in “hugin” package in Ubuntu: Invalid Bug description: Hi, this is mostly a duplicate of https://bugs.launchpad.net/enblend/+bug/1220523. I would like to add that the diagnostic messages and documentation could be a lot better in this situation. Instead of enblend: No space left on device it would be much more helpfull to say *which device/dricetory* as this does not appear documented anywhere. Furthermore, is this device hardcoded in the source code or is it configurable somewhere? Again, did not find anything in the documentation. Finally, this just happened to me with $ df /tmp/ Filesystem 1K-blocks Used Available Use% Mounted on tmpfs1028148 924 1027224 1% /tmp and trying to stitch together 31 images. It would seem that similar situations may become increasingly common in the near future. Regards To manage notifications about this bug go to: https://bugs.launchpad.net/enblend/+bug/1384674/+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 807439] Re: Artefacts due to Enblend memory bug
The ImageCache causing the problem was withdrawn in the Development Branch, which finally leads to version 4.2. So the bug is gone there, because the code that caused it was removed. We have a tentative replacement for the ImageCache in the mmap_view branch: http://hg.code.sf.net/p/enblend/code/rev/7a3964af671a However, the developers are still unsure whether the new code is (a) fast enough and (b) offloads sufficient image data from core memory to disk. Right now it is uncertain whether mmap_view will make it into the mainline Development Branch. -- You received this bug notification because you are a member of Hugin Developers, which is subscribed to Hugin. https://bugs.launchpad.net/bugs/807439 Title: Artefacts due to Enblend memory bug Status in Enblend: Confirmed Status in Hugin - Panorama Tools GUI: Confirmed Bug description: Please take a look at my equirectangular panorama http://img11.imageshack.us/img11/7831/test24.jpg What happened to those exposure line? Also the nadir image result is equally weired. If I use normal view with horizontal horizon ,it looks like something broken: http://img18.imageshack.us/img18/6176/48761613.png But if I chang the view and looking down, it appears fine: http://img59.imageshack.us/img59/1462/47884439.png I don't get it, is there anything I'm not doing right? I've use manual mode for everything when shooting (e.g. white balance, aperture, exposure time. ) I using prebuilt hugin for Windows 7 64bit.(HuginSetup_2011.2.0-beta1_64bit_Windows_2.exe ) Also take a look at the discussion at google form https://groups.google.com/forum/?pli=1#!topic/hugin-ptx/RQz4-I_LGss To manage notifications about this bug go to: https://bugs.launchpad.net/enblend/+bug/807439/+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 1384674] Re: enblend running out of temp space: poor diagnostics and configuration possibilities
The environment variable `TMPDIR' controls the placement of temporary files as documented in section Tuning Memory Usage of the Enblend and Enfuse manuals. The actual, assigned directory for the ImageCache can easily be inquired by calling Enblend or Enfuse with the option pair `--verbose --version' or shorter `-Vv', and the relevant part of answer looks like this: Extra feature: image cache: yes - environment variable TMPDIR not set, cache file in default directory /tmp or Extra feature: image cache: yes - environment variable TMPDIR set, cache file located in /work if TMPDIR=/work Both options, `--verbose' and `--version' are documented, too. The user is responsible for setting up TMPDIR (if required at all) as well as for feeding properly overlapping images with suitable alpha channel into Enblend or Enfuse. -- You received this bug notification because you are a member of Hugin Developers, which is subscribed to Enblend. https://bugs.launchpad.net/bugs/1384674 Title: enblend running out of temp space: poor diagnostics and configuration possibilities Status in Enblend: New Status in “hugin” package in Ubuntu: Invalid Bug description: Hi, this is mostly a duplicate of https://bugs.launchpad.net/enblend/+bug/1220523. I would like to add that the diagnostic messages and documentation could be a lot better in this situation. Instead of enblend: No space left on device it would be much more helpfull to say *which device/dricetory* as this does not appear documented anywhere. Furthermore, is this device hardcoded in the source code or is it configurable somewhere? Again, did not find anything in the documentation. Finally, this just happened to me with $ df /tmp/ Filesystem 1K-blocks Used Available Use% Mounted on tmpfs1028148 924 1027224 1% /tmp and trying to stitch together 31 images. It would seem that similar situations may become increasingly common in the near future. Regards To manage notifications about this bug go to: https://bugs.launchpad.net/enblend/+bug/1384674/+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 1372700] Re: Blending error
** Changed in: enblend Status: New = Won't Fix -- You received this bug notification because you are a member of Hugin Developers, which is subscribed to Enblend. https://bugs.launchpad.net/bugs/1372700 Title: Blending error Status in Enblend: Won't Fix Bug description: Using test images supplied by Hans Bull, I get a blending error using Enblend 4.2.0 (1116:fd5bc9fbf096). The blending error does not occur with Multiblend. This error appears to be particularly sensitive to the crop boundary. I have not been able to reproduce the error for any other settings than those in the .pto file. Attached images, .pto and resulting stitch. I am using Fedora 20 x86_64 hugin-2014.1.0 (current default) To manage notifications about this bug go to: https://bugs.launchpad.net/enblend/+bug/1372700/+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 1372700] Re: Blending error
Brief answer: `-a' Less brief answer: (0, 4, 3, 1, 2) Readable answer: In the canonical order, the first pair of images already does *not* overlap and Enblend issues a (deserved) warning. Re-order the images e.g. as (0, 4, 3, 1, 2) or stick with the canonical order and pass the pre-assemble option `-a'. The behavior you experience is expected as Enblend's algorithm adds one image after the other, blending each with the *result* of all images before. This is described in the user manual. I prepared a set of patches that (1) Give pre-assembling a more prominent position by adding long forms `--pre-assemble' and `--no-pre-assemble'. (2) Exploit more parallelism in the pre-assembly code path. (3) Give a more descriptive warning when encountering non-overlaps. Please contact me by email if you are interested in alpha-testing these patches. If we let us guide by the principle-of-least-surprise, even a program abort is conceivable in case (3). What do you think? As you are an extraordinarily experienced user of Enblend and a native speaker of English (one excuse less, he he!) you are cordially invited to improve on the Enblend user manual to further clarify the default `one-by-one' and `pre-assemble' variants. -- You received this bug notification because you are a member of Hugin Developers, which is subscribed to Enblend. https://bugs.launchpad.net/bugs/1372700 Title: Blending error Status in Enblend: New Bug description: Using test images supplied by Hans Bull, I get a blending error using Enblend 4.2.0 (1116:fd5bc9fbf096). The blending error does not occur with Multiblend. This error appears to be particularly sensitive to the crop boundary. I have not been able to reproduce the error for any other settings than those in the .pto file. Attached images, .pto and resulting stitch. I am using Fedora 20 x86_64 hugin-2014.1.0 (current default) To manage notifications about this bug go to: https://bugs.launchpad.net/enblend/+bug/1372700/+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 1356551] Re: White pixels at 180 wrap and zenith for 16/32bit HDR Pano
Rosomack reviewed the proposed patches and found them ok. Changes applied in revs 255771c2e58b http://hg.code.sf.net/p/enblend/code/rev/255771c2e58 and 95c7e90f2be8 http://hg.code.sf.net/p/enblend/code/rev/95c7e90f2be8 ** Changed in: enblend Status: In Progress = Fix Committed -- You received this bug notification because you are a member of Hugin Developers, which is subscribed to Enblend. https://bugs.launchpad.net/bugs/1356551 Title: White pixels at 180 wrap and zenith for 16/32bit HDR Pano Status in Enblend: Fix Committed Status in Hugin - Panorama Tools GUI: Invalid Bug description: When stitching my final pano for an HDR workflow I get a column of blank/white pixels near the equator at the 180 wrap and an entire row of blank/white pixels at the top. Here's the basic pieces of my workflow: - Multiple exposures at 7 angles with samyang 8mm + pano head - Combined exposures to 7 HDR images using pfstools (sometimes exr files for 16bpp, other times tiff for 32bpp) - Use hugin to: mask out pano head arm, find control points, optimize positions, barrel and view and set output options - Stitch with a script using nona+enblend to equirec HDR image Can view example of the white pixels here: - you're facing the 180 wrap when it first comes up - zoom in at zenith to see the missing top pixel http://vr.rollerblading.es/pano/file?path=https://dl.dropboxusercontent.com/u/3340541/Panos/MuralLobby-Pano-LDR.jpg When I look at intermediate files I'm pretty sure it is enblend that is the source of the problem. I've tried several different versions: - The stock version from the OSX binary on the source forge web site (v 4.1.1) - Enblend 4.1.2_2 compiled with macports - Enblend 4.1.3 compiled with macports (using my own updated portfile to grab the 4.1.3 tar ball) All three versions show the same problem. I'll attach a screenshot pointing out the truant pixels as well as a minimal .pto file and the script I use for stitching. To manage notifications about this bug go to: https://bugs.launchpad.net/enblend/+bug/1356551/+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 1364695] Re: Enblend incorrectly warns of mismatched ICC profiles
Fixed in rev 3e1c4bc71018. ** Changed in: enblend Status: Incomplete = Fix Committed ** Changed in: enblend Importance: Undecided = Low ** Changed in: enblend Assignee: (unassigned) = Christoph Spiel (cspiel) -- You received this bug notification because you are a member of Hugin Developers, which is subscribed to Enblend. https://bugs.launchpad.net/bugs/1364695 Title: Enblend incorrectly warns of mismatched ICC profiles Status in Enblend: Fix Committed Bug description: Reproduce: 1. Export RAW images as tif from Darktable, with either the 'linear Rec709 RGB' or 'Adobe RGB' settings. (These are the only color spaces I have tried so far) 2. Import into Hugin, create panorama, use enblend as the blending operator 3. Terminal reports non-blocking messages such as below: enblend: warning: input image tiger3d0003.tif enblend: warning: has ICC profile Darktable linear Rec709 RGB, enblend: warning: but first image has ICC profile Darktable linear Rec709 RGB; enblend: warning: blending images with different color spaces enblend: warning: may have unexpected results Not a critical bug, but enblend shouldn't be warning about differing color spaces when they are obviously identical. To manage notifications about this bug go to: https://bugs.launchpad.net/enblend/+bug/1364695/+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 1364695] Re: Enblend incorrectly warns of mismatched ICC profiles
In a test with a six image project, where the input images were generated by the current tip of Darktable and given a ProPhoto ICC profile no warnings show up with Enblend (also current tip of Dev Branch). ** Changed in: enblend Status: New = Incomplete -- You received this bug notification because you are a member of Hugin Developers, which is subscribed to Enblend. https://bugs.launchpad.net/bugs/1364695 Title: Enblend incorrectly warns of mismatched ICC profiles Status in Enblend: Incomplete Bug description: Reproduce: 1. Export RAW images as tif from Darktable, with either the 'linear Rec709 RGB' or 'Adobe RGB' settings. (These are the only color spaces I have tried so far) 2. Import into Hugin, create panorama, use enblend as the blending operator 3. Terminal reports non-blocking messages such as below: enblend: warning: input image tiger3d0003.tif enblend: warning: has ICC profile Darktable linear Rec709 RGB, enblend: warning: but first image has ICC profile Darktable linear Rec709 RGB; enblend: warning: blending images with different color spaces enblend: warning: may have unexpected results Not a critical bug, but enblend shouldn't be warning about differing color spaces when they are obviously identical. To manage notifications about this bug go to: https://bugs.launchpad.net/enblend/+bug/1364695/+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 1356551] Re: White pixels at 180 wrap and zenith for 16/32bit HDR Pano
Meanwhile I think I know what the problem is. My solution, however, would break a considerable amount of Enblend code. Therefore, I'll pass on the issue to another developer. Hopefully he will come up with a less sizable patch. -- You received this bug notification because you are a member of Hugin Developers, which is subscribed to Enblend. https://bugs.launchpad.net/bugs/1356551 Title: White pixels at 180 wrap and zenith for 16/32bit HDR Pano Status in Enblend: In Progress Status in Hugin - Panorama Tools GUI: Invalid Bug description: When stitching my final pano for an HDR workflow I get a column of blank/white pixels near the equator at the 180 wrap and an entire row of blank/white pixels at the top. Here's the basic pieces of my workflow: - Multiple exposures at 7 angles with samyang 8mm + pano head - Combined exposures to 7 HDR images using pfstools (sometimes exr files for 16bpp, other times tiff for 32bpp) - Use hugin to: mask out pano head arm, find control points, optimize positions, barrel and view and set output options - Stitch with a script using nona+enblend to equirec HDR image Can view example of the white pixels here: - you're facing the 180 wrap when it first comes up - zoom in at zenith to see the missing top pixel http://vr.rollerblading.es/pano/file?path=https://dl.dropboxusercontent.com/u/3340541/Panos/MuralLobby-Pano-LDR.jpg When I look at intermediate files I'm pretty sure it is enblend that is the source of the problem. I've tried several different versions: - The stock version from the OSX binary on the source forge web site (v 4.1.1) - Enblend 4.1.2_2 compiled with macports - Enblend 4.1.3 compiled with macports (using my own updated portfile to grab the 4.1.3 tar ball) All three versions show the same problem. I'll attach a screenshot pointing out the truant pixels as well as a minimal .pto file and the script I use for stitching. To manage notifications about this bug go to: https://bugs.launchpad.net/enblend/+bug/1356551/+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 1364695] Re: Enblend incorrectly warns of mismatched ICC profiles
This might be surprising. FYI, Enblend and Enfuse don't simply compare the profiles' ASCII names, but judge profile equality by comparison of the whole profile as returned by vigra::ImageImportInfo::getICCProfile() We don't dig deeper into any difference than just throwing the warning you see. -- You received this bug notification because you are a member of Hugin Developers, which is subscribed to Enblend. https://bugs.launchpad.net/bugs/1364695 Title: Enblend incorrectly warns of mismatched ICC profiles Status in Enblend: New Bug description: Reproduce: 1. Export RAW images as tif from Darktable, with either the 'linear Rec709 RGB' or 'Adobe RGB' settings. (These are the only color spaces I have tried so far) 2. Import into Hugin, create panorama, use enblend as the blending operator 3. Terminal reports non-blocking messages such as below: enblend: warning: input image tiger3d0003.tif enblend: warning: has ICC profile Darktable linear Rec709 RGB, enblend: warning: but first image has ICC profile Darktable linear Rec709 RGB; enblend: warning: blending images with different color spaces enblend: warning: may have unexpected results Not a critical bug, but enblend shouldn't be warning about differing color spaces when they are obviously identical. To manage notifications about this bug go to: https://bugs.launchpad.net/enblend/+bug/1364695/+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 1356551] Re: White pixels at 180 wrap and zenith for 16/32bit HDR Pano
THX for the concise example. I can reproduce the bug on my machines. ** Changed in: enblend Status: New = In Progress ** Changed in: enblend Importance: Undecided = Medium ** Changed in: enblend Assignee: (unassigned) = Christoph Spiel (cspiel) -- You received this bug notification because you are a member of Hugin Developers, which is subscribed to Enblend. https://bugs.launchpad.net/bugs/1356551 Title: White pixels at 180 wrap and zenith for 16/32bit HDR Pano Status in Enblend: In Progress Status in Hugin - Panorama Tools GUI: Invalid Bug description: When stitching my final pano for an HDR workflow I get a column of blank/white pixels near the equator at the 180 wrap and an entire row of blank/white pixels at the top. Here's the basic pieces of my workflow: - Multiple exposures at 7 angles with samyang 8mm + pano head - Combined exposures to 7 HDR images using pfstools (sometimes exr files for 16bpp, other times tiff for 32bpp) - Use hugin to: mask out pano head arm, find control points, optimize positions, barrel and view and set output options - Stitch with a script using nona+enblend to equirec HDR image Can view example of the white pixels here: - you're facing the 180 wrap when it first comes up - zoom in at zenith to see the missing top pixel http://vr.rollerblading.es/pano/file?path=https://dl.dropboxusercontent.com/u/3340541/Panos/MuralLobby-Pano-LDR.jpg When I look at intermediate files I'm pretty sure it is enblend that is the source of the problem. I've tried several different versions: - The stock version from the OSX binary on the source forge web site (v 4.1.1) - Enblend 4.1.2_2 compiled with macports - Enblend 4.1.3 compiled with macports (using my own updated portfile to grab the 4.1.3 tar ball) All three versions show the same problem. I'll attach a screenshot pointing out the truant pixels as well as a minimal .pto file and the script I use for stitching. To manage notifications about this bug go to: https://bugs.launchpad.net/enblend/+bug/1356551/+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 1356551] Re: White pixels at 180 wrap and zenith for 16/32bit HDR Pano
We'd need a set of input images for Enblend that clearly reproduce the problem preferably with the tip of the development branch. Otherwise we waste our time with guesswork. -- You received this bug notification because you are a member of Hugin Developers, which is subscribed to Enblend. https://bugs.launchpad.net/bugs/1356551 Title: White pixels at 180 wrap and zenith for 16/32bit HDR Pano Status in Enblend: New Status in Hugin - Panorama Tools GUI: Invalid Bug description: When stitching my final pano for an HDR workflow I get a column of blank/white pixels near the equator at the 180 wrap and an entire row of blank/white pixels at the top. Here's the basic pieces of my workflow: - Multiple exposures at 7 angles with samyang 8mm + pano head - Combined exposures to 7 HDR images using pfstools (sometimes exr files for 16bpp, other times tiff for 32bpp) - Use hugin to: mask out pano head arm, find control points, optimize positions, barrel and view and set output options - Stitch with a script using nona+enblend to equirec HDR image Can view example of the white pixels here: - you're facing the 180 wrap when it first comes up - zoom in at zenith to see the missing top pixel http://vr.rollerblading.es/pano/file?path=https://dl.dropboxusercontent.com/u/3340541/Panos/MuralLobby-Pano-LDR.jpg When I look at intermediate files I'm pretty sure it is enblend that is the source of the problem. I've tried several different versions: - The stock version from the OSX binary on the source forge web site (v 4.1.1) - Enblend 4.1.2_2 compiled with macports - Enblend 4.1.3 compiled with macports (using my own updated portfile to grab the 4.1.3 tar ball) All three versions show the same problem. I'll attach a screenshot pointing out the truant pixels as well as a minimal .pto file and the script I use for stitching. To manage notifications about this bug go to: https://bugs.launchpad.net/enblend/+bug/1356551/+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 1332323] Re: Fix issues reported by valgrind
Committed #0001 in http://hg.code.sf.net/p/enblend/code/rev/18a9c1d411ac. ** Changed in: enblend Status: In Progress = Fix Committed -- You received this bug notification because you are a member of Hugin Developers, which is subscribed to Enblend. https://bugs.launchpad.net/bugs/1332323 Title: Fix issues reported by valgrind Status in Enblend: Fix Committed Bug description: Hi everyone, I ran enblend under valgrind which reported several issues. The first one is a simple missing initialization. The other ones are mostly about bad usage of boost::scoped_ptr. I have two different approaches to fix this: 1. Directly write into std::string buffer instead of using a temporary char[] buffer. This is guaranteed behavior by C++11, see e.g. http://herbsutter.com/2008/04/07/cringe-not-vectors-are-guaranteed-to-be-contiguous/#comment-483 2. Use a boost::tokenizer. As it does not need a char[] buffer, different to strtok, no need to allocate one. This has the nice side effect to get rid of the homegrown enblend::strtoken_r tokenizer. Kind regards, Stefan To manage notifications about this bug go to: https://bugs.launchpad.net/enblend/+bug/1332323/+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 1332323] Re: Fix issues reported by valgrind
THX for your thorough analysis! I'm willing to apply all of your patches, however only #1 applies cleanly against the head of the development branch. Could you please be so kind and rework the others? Our development policy is to test all changes in the development branch before migrating any of them to the stable branch. ** Changed in: enblend Status: New = In Progress ** Changed in: enblend Importance: Undecided = Low ** Changed in: enblend Assignee: (unassigned) = Christoph Spiel (cspiel) -- You received this bug notification because you are a member of Hugin Developers, which is subscribed to Enblend. https://bugs.launchpad.net/bugs/1332323 Title: Fix issues reported by valgrind Status in Enblend: In Progress Bug description: Hi everyone, I ran enblend under valgrind which reported several issues. The first one is a simple missing initialization. The other ones are mostly about bad usage of boost::scoped_ptr. I have two different approaches to fix this: 1. Directly write into std::string buffer instead of using a temporary char[] buffer. This is guaranteed behavior by C++11, see e.g. http://herbsutter.com/2008/04/07/cringe-not-vectors-are-guaranteed-to-be-contiguous/#comment-483 2. Use a boost::tokenizer. As it does not need a char[] buffer, different to strtok, no need to allocate one. This has the nice side effect to get rid of the homegrown enblend::strtoken_r tokenizer. Kind regards, Stefan To manage notifications about this bug go to: https://bugs.launchpad.net/enblend/+bug/1332323/+subscriptions ___ Mailing list: https://launchpad.net/~hugin-devs Post to : hugin-devs@lists.launchpad.net Unsubscribe : https://launchpad.net/~hugin-devs More help : https://help.launchpad.net/ListHelp
[Hugin-devs] [Bug 1316967] Re: Maximum TIFF file size 4GB
** Changed in: enblend Importance: Undecided = Wishlist ** Changed in: enblend Status: New = Triaged -- You received this bug notification because you are a member of Hugin Developers, which is subscribed to Enblend. https://bugs.launchpad.net/bugs/1316967 Title: Maximum TIFF file size 4GB Status in Enblend: Triaged Bug description: Hi there! After running for 2 days the enblend binary that I compiled myself from the enblend sources revision 1049 failed with this error: enblend: info: writing final output enblend: error: Maximum TIFF file size exceeded enblend: an exception occured enblend: Postcondition violation! exportImage(): Unable to write TIFF data. (/build/buildd/libvigraimpex-1.9.0+dfsg/src/impex/tiff.cxx:811) enblend: info: remove invalid output image x1.tif === I've used these parameters: --compression=LZW --verbose --output=x1.tif The output pixel dimensions would have been 119598 * 17362 = 2076460476 which is still well within the 2^31 pixel count limit = 2147483648 In the bug report #685105 I've mentioned that I've run into this problem before, and back then Jeff Hungerford (hungerf3) told me: If you are seeing that error, either the TIFF library you linked against doesn't support bigTIFF, or for some reason it decided to only use the old format. It would be very kind of you if you could guide my way how to compile enblend (and libtiff?) in a way that enblend will not fail when the output exceeds 4GB in file size. Or is there maybe a way to use another output format then tif to workaround this problem? (With Gimp I like to use png for images that are too big for 4GB tif, it has the same problem of failing to save 4GB tiffs for me) To manage notifications about this bug go to: https://bugs.launchpad.net/enblend/+bug/1316967/+subscriptions ___ Mailing list: https://launchpad.net/~hugin-devs Post to : hugin-devs@lists.launchpad.net Unsubscribe : https://launchpad.net/~hugin-devs More help : https://help.launchpad.net/ListHelp
[Hugin-devs] [Bug 1316967] Re: Maximum TIFF file size 4GB
This is not an Enblend (or Enfuse) problem. Both applications rely on the Vigra library for I/O of images of _any_ format, i.e. the functions described in https://ukoethe.github.io/vigra/doc/vigra/group__VigraImpex.html This is in fact one of the main reasons to use an imaging library as e.g. Vigra. You could ask the Vigra developers for integration of BigTIFF into Vigra or even supply the necessary patch yourself. -- You received this bug notification because you are a member of Hugin Developers, which is subscribed to Enblend. https://bugs.launchpad.net/bugs/1316967 Title: Maximum TIFF file size 4GB Status in Enblend: New Bug description: Hi there! After running for 2 days the enblend binary that I compiled myself from the enblend sources revision 1049 failed with this error: enblend: info: writing final output enblend: error: Maximum TIFF file size exceeded enblend: an exception occured enblend: Postcondition violation! exportImage(): Unable to write TIFF data. (/build/buildd/libvigraimpex-1.9.0+dfsg/src/impex/tiff.cxx:811) enblend: info: remove invalid output image x1.tif === I've used these parameters: --compression=LZW --verbose --output=x1.tif The output pixel dimensions would have been 119598 * 17362 = 2076460476 which is still well within the 2^31 pixel count limit = 2147483648 In the bug report #685105 I've mentioned that I've run into this problem before, and back then Jeff Hungerford (hungerf3) told me: If you are seeing that error, either the TIFF library you linked against doesn't support bigTIFF, or for some reason it decided to only use the old format. It would be very kind of you if you could guide my way how to compile enblend (and libtiff?) in a way that enblend will not fail when the output exceeds 4GB in file size. Or is there maybe a way to use another output format then tif to workaround this problem? (With Gimp I like to use png for images that are too big for 4GB tif, it has the same problem of failing to save 4GB tiffs for me) To manage notifications about this bug go to: https://bugs.launchpad.net/enblend/+bug/1316967/+subscriptions ___ Mailing list: https://launchpad.net/~hugin-devs Post to : hugin-devs@lists.launchpad.net Unsubscribe : https://launchpad.net/~hugin-devs More help : https://help.launchpad.net/ListHelp
[Hugin-devs] [Bug 1305794] Re: OpenCL enabled build fails
** Changed in: enblend Status: New = Won't Fix -- You received this bug notification because you are a member of Hugin Developers, which is subscribed to Enblend. https://bugs.launchpad.net/bugs/1305794 Title: OpenCL enabled build fails Status in Enblend: Won't Fix Bug description: My newly built enblend binary printed a lot of those lines: enblend: info: no OpenCL support compiled into Enblend So I looked into how to compile enblend with OpenCL support. I've found this cmake switch: -DENABLE_OPENCL:BOOL=ON and this package in my repos: nvidia-opencl-dev Next I got an error from make package right at the beginning: /bin/sh: 1: cannot create /home/kaefert/src/enblend/enblend.build_1044/src/kernels/distance_transform_fh.icl: Directory nonexistent So I created the directory manually, and now my compiling fails after 44% with a lot of lines like those: opencl.cc:(.text._ZN3ocl12LazyFunctionINS_16SourceFilePolicyEE5buildERKSs[_ZN3ocl12LazyFunctionINS_16SourceFilePolicyEE5buildERKSs]+0x1d6): undefined reference to `clReleaseDevice' opencl.cc:(.text._ZN3ocl12LazyFunctionINS_16SourceFilePolicyEE5buildERKSs[_ZN3ocl12LazyFunctionINS_16SourceFilePolicyEE5buildERKSs]+0x2d9): undefined reference to `clRetainDevice' To manage notifications about this bug go to: https://bugs.launchpad.net/enblend/+bug/1305794/+subscriptions ___ Mailing list: https://launchpad.net/~hugin-devs Post to : hugin-devs@lists.launchpad.net Unsubscribe : https://launchpad.net/~hugin-devs More help : https://help.launchpad.net/ListHelp
[Hugin-devs] [Bug 1305643] Re: enblend build errors with changeset 1044
Technically, your Boost headers (and libraries) are too old. So, this is not an Enblend/Enfuse problem. I have just committed a patch that requires at least Boost version 1.55 to build Enblend and Enfuse. ** Changed in: enblend Status: Fix Committed = Won't Fix -- You received this bug notification because you are a member of Hugin Developers, which is subscribed to Enblend. https://bugs.launchpad.net/bugs/1305643 Title: enblend build errors with changeset 1044 Status in Enblend: Won't Fix Bug description: I'm trying to compile enblend, using this guide here: http://wiki.panotools.org/Hugin_Compiling_Ubuntu Previously this worked fine, but now I get those compile errors: In file included from /home/kaefert/src/enblend/enblend.hg/src/enblend.cc:178:0: /home/kaefert/src/enblend/enblend.hg/src/common.h: In function ‘std::string enblend::expandFilenameTemplate(const string, unsigned int, const string, const string, unsigned int)’: /home/kaefert/src/enblend/enblend.hg/src/common.h:732:25: error: ‘BOOST_FALLTHROUGH’ was not declared in this scope BOOST_FALLTHROUGH; ^ In file included from /home/kaefert/src/enblend/enblend.hg/src/mask.h:40:0, from /home/kaefert/src/enblend/enblend.hg/src/enblend.h:45, from /home/kaefert/src/enblend/enblend.hg/src/enblend.cc:180: /home/kaefert/src/enblend/enblend.hg/include/vigra_ext/fillpolygon.hxx: In function ‘void vigra_ext::detail::group_to_pairs(Iterator, Iterator, BackInsertIterator)’: /home/kaefert/src/enblend/enblend.hg/include/vigra_ext/fillpolygon.hxx:255:21: error: ‘BOOST_FALLTHROUGH’ was not declared in this scope BOOST_FALLTHROUGH; ^ make[2]: *** [src/CMakeFiles/enblend.dir/enblend.cc.o] Error 1 make[1]: *** [src/CMakeFiles/enblend.dir/all] Error 2 make: *** [all] Error 2 Last time I had problems compiling enblend I could work around them by changing -DCMAKE_BUILD_TYPE=RelWithDebInfo into -DCMAKE_BUILD_TYPE=Debug - but this time that switch doesn't make any difference. To manage notifications about this bug go to: https://bugs.launchpad.net/enblend/+bug/1305643/+subscriptions ___ Mailing list: https://launchpad.net/~hugin-devs Post to : hugin-devs@lists.launchpad.net Unsubscribe : https://launchpad.net/~hugin-devs More help : https://help.launchpad.net/ListHelp
[Hugin-devs] [Bug 1305794] Re: OpenCL enabled build fails
WRT your original errors. They point to outdated OpenCL header files. Ask your sysadmin to get the most recent versions from http://www.khronos.org/opencl/ and install them in the appropriate place. Next thing on her agenda is to update the OpenCL libraries to their latest versions. Again, the older versions tend to be much buggier than recent ones. The complete OpenCL environment (headers, drivers, libraries, etc.) must work perfectly before you can expect Enblend to even try to utilize the GPU. -- You received this bug notification because you are a member of Hugin Developers, which is subscribed to Enblend. https://bugs.launchpad.net/bugs/1305794 Title: OpenCL enabled build fails Status in Enblend: New Bug description: My newly built enblend binary printed a lot of those lines: enblend: info: no OpenCL support compiled into Enblend So I looked into how to compile enblend with OpenCL support. I've found this cmake switch: -DENABLE_OPENCL:BOOL=ON and this package in my repos: nvidia-opencl-dev Next I got an error from make package right at the beginning: /bin/sh: 1: cannot create /home/kaefert/src/enblend/enblend.build_1044/src/kernels/distance_transform_fh.icl: Directory nonexistent So I created the directory manually, and now my compiling fails after 44% with a lot of lines like those: opencl.cc:(.text._ZN3ocl12LazyFunctionINS_16SourceFilePolicyEE5buildERKSs[_ZN3ocl12LazyFunctionINS_16SourceFilePolicyEE5buildERKSs]+0x1d6): undefined reference to `clReleaseDevice' opencl.cc:(.text._ZN3ocl12LazyFunctionINS_16SourceFilePolicyEE5buildERKSs[_ZN3ocl12LazyFunctionINS_16SourceFilePolicyEE5buildERKSs]+0x2d9): undefined reference to `clRetainDevice' To manage notifications about this bug go to: https://bugs.launchpad.net/enblend/+bug/1305794/+subscriptions ___ Mailing list: https://launchpad.net/~hugin-devs Post to : hugin-devs@lists.launchpad.net Unsubscribe : https://launchpad.net/~hugin-devs More help : https://help.launchpad.net/ListHelp
[Hugin-devs] [Bug 1157155] Re: enblend 4.1 generates brighter images than originals
@Frederic: Thanks for investigation the problem! From revision 502d69450811 Enblend and Enfuse require at least Little CMS version 2.5. We hope to backport the patch to the stable series soon. ** Changed in: enblend Status: Incomplete = Fix Committed ** Changed in: enblend Importance: Undecided = Medium -- You received this bug notification because you are a member of Hugin Developers, which is subscribed to Enblend. https://bugs.launchpad.net/bugs/1157155 Title: enblend 4.1 generates brighter images than originals Status in Enblend: Fix Committed Bug description: I just notice that the recent versions of enblend (4.1 I think) generates a panorama image which is much more brighter than the original JPEGs. When the original JPEGs contain some black or dark areas, they becomes grey (like a problem of gamma). I check with Gimp and the histogram no longer contains black or dark colors as if it was compressed at right. As I didn't remember this kind of problems with previous enblend versions, I looked in recent options like CIECAM02 which is enabled by default. And, when I use --no-ciecam, the problem disappears. (In my case, all my original JPEGs are in sRGB and for this test case, I haven't done any exposition correction in Hugin : I just compare the result by adding and removing --no-ciecam). So, is it a regression or an expected behaviour ? To manage notifications about this bug go to: https://bugs.launchpad.net/enblend/+bug/1157155/+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.
Lukas, THX for your minimal example! Admittedly, I cannot reproduce your foo.tif with rev 6d6c88dcdc63, i.e. current tip. I tried any image order, NFT, GC, w/optimizer, and wo/optimizer. The result _always_ looked ok and never showed any black areas. Moreover the seam line (`--visualize') between the image pairs was sane, too. Maybe the bug you were hunting for such a long time is gone now. OTOH, I have example images from Bruno which let the seamline vectorizer go postal. So, there are some bugs left that can cause black areas. (Usage of plural to be on the safe side.) -- You received this bug notification because you are a member of Hugin Developers, which is subscribed to Enblend. https://bugs.launchpad.net/bugs/721136 Title: enblend creates an unexplainable black area. Status in Enblend: Confirmed Bug description: enblending http://prive.bitwizard.nl/t80001.tif and http://prive.bitwizard.nl/t80003.tif results in http://prive.bitwizard.nl/t8a.tif I cannot say I expected that black triangle in the output. My enblend was pulled from hg this morning (no changes) and built without imagecache or openMP. (imagecache causes corruption of the output similar but different to this. ) To manage notifications about this bug go to: https://bugs.launchpad.net/enblend/+bug/721136/+subscriptions ___ Mailing list: https://launchpad.net/~hugin-devs Post to : hugin-devs@lists.launchpad.net Unsubscribe : https://launchpad.net/~hugin-devs More help : https://help.launchpad.net/ListHelp
[Hugin-devs] [Bug 721136] Re: enblend creates an unexplainable black area.
@Lukas: (i) GraphCut is absolutely unchanged in 6d6c88dc, (ii) after its recent re-implementation it is again WIP according to its author. Please run with NFT only to see whether this fundamental step now works any better. BTW, GraphCut uses NFT as an educated guess. If you have a reasonably sized set of images, I'd be interested in looking at the problem myself. THX for testing! -- You received this bug notification because you are a member of Hugin Developers, which is subscribed to Enblend. https://bugs.launchpad.net/bugs/721136 Title: enblend creates an unexplainable black area. Status in Enblend: Confirmed Bug description: enblending http://prive.bitwizard.nl/t80001.tif and http://prive.bitwizard.nl/t80003.tif results in http://prive.bitwizard.nl/t8a.tif I cannot say I expected that black triangle in the output. My enblend was pulled from hg this morning (no changes) and built without imagecache or openMP. (imagecache causes corruption of the output similar but different to this. ) To manage notifications about this bug go to: https://bugs.launchpad.net/enblend/+bug/721136/+subscriptions ___ Mailing list: https://launchpad.net/~hugin-devs Post to : hugin-devs@lists.launchpad.net Unsubscribe : https://launchpad.net/~hugin-devs More help : https://help.launchpad.net/ListHelp
[Hugin-devs] [Bug 685875] Re: severe ghosting in cloud row
** Changed in: enblend Status: New = Incomplete -- You received this bug notification because you are a member of Hugin Developers, which is subscribed to Enblend. https://bugs.launchpad.net/bugs/685875 Title: severe ghosting in cloud row Status in Enblend: Incomplete Bug description: for a description of this issue see this thread at the hugin-ptx google group: http://groups.google.com/group/hugin- ptx/browse_thread/thread/671cd50a44211ca8?hl=en. the last three posts (under the name kunlun121) show my problem and provide a download link. i have downloaded an older version 3.1 (svn3176) that does not show the problem. this version was downloaded from harry van der wolf's web site (here: http://panorama.dyndns.org/index.php?lang=ENsubject=Hugintexttag=Hugin). To manage notifications about this bug go to: https://bugs.launchpad.net/enblend/+bug/685875/+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 785803] Re: Enblend --no-optimize produces black holes into panoramas
Check out rev 6d6c88dcdc63 or later. Keep optimization switched off and -- at your discretion GraphCut -- to get reliable results. -- You received this bug notification because you are a member of Hugin Developers, which is subscribed to Enblend. https://bugs.launchpad.net/bugs/785803 Title: Enblend --no-optimize produces black holes into panoramas Status in Enblend: Confirmed Bug description: --no-optimize: http://i.imgur.com/Bc9hD.jpg How it should look: http://i.imgur.com/MAyhz.jpg Win7 x64 w/ 32bit and x64 Hugin 2011.1 RC1 (2011.0.0.8f1447ab8649 built by Matthew Petroff), multithreaded Enblend. Project contains less than ten fisheye images encompassing the whole panosphere, so it's your average spherical panorama. You can see how much the images overlap here: http://i.imgur.com/KuAqU.jpg I think the issue could be related to too small overlap between images. To manage notifications about this bug go to: https://bugs.launchpad.net/enblend/+bug/785803/+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.
Check out rev 6d6c88dcdc63 or later. Switch off optimization and -- at your discretion GraphCut -- to get reliable results. -- You received this bug notification because you are a member of Hugin Developers, which is subscribed to Enblend. https://bugs.launchpad.net/bugs/721136 Title: enblend creates an unexplainable black area. Status in Enblend: Confirmed Bug description: enblending http://prive.bitwizard.nl/t80001.tif and http://prive.bitwizard.nl/t80003.tif results in http://prive.bitwizard.nl/t8a.tif I cannot say I expected that black triangle in the output. My enblend was pulled from hg this morning (no changes) and built without imagecache or openMP. (imagecache causes corruption of the output similar but different to this. ) To manage notifications about this bug go to: https://bugs.launchpad.net/enblend/+bug/721136/+subscriptions ___ Mailing list: https://launchpad.net/~hugin-devs Post to : hugin-devs@lists.launchpad.net Unsubscribe : https://launchpad.net/~hugin-devs More help : https://help.launchpad.net/ListHelp
[Hugin-devs] [Bug 785803] Re: Enblend --no-optimize produces black holes into panoramas
** Changed in: enblend Importance: Undecided = Medium -- You received this bug notification because you are a member of Hugin Developers, which is subscribed to Enblend. https://bugs.launchpad.net/bugs/785803 Title: Enblend --no-optimize produces black holes into panoramas Status in Enblend: Confirmed Bug description: --no-optimize: http://i.imgur.com/Bc9hD.jpg How it should look: http://i.imgur.com/MAyhz.jpg Win7 x64 w/ 32bit and x64 Hugin 2011.1 RC1 (2011.0.0.8f1447ab8649 built by Matthew Petroff), multithreaded Enblend. Project contains less than ten fisheye images encompassing the whole panosphere, so it's your average spherical panorama. You can see how much the images overlap here: http://i.imgur.com/KuAqU.jpg I think the issue could be related to too small overlap between images. To manage notifications about this bug go to: https://bugs.launchpad.net/enblend/+bug/785803/+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 739057] Re: Initial seam line has undesirable corners when near diagonal
Please add your (pair of) input images to this issue report such that we can test with the latest revision of Enblend. ** Changed in: enblend Status: New = Incomplete -- You received this bug notification because you are a member of Hugin Developers, which is subscribed to Enblend. https://bugs.launchpad.net/bugs/739057 Title: Initial seam line has undesirable corners when near diagonal Status in Enblend: Incomplete Bug description: The initial seam line between two images, where the best seam is close to being diagonal, end up with large horizontal/vertical deviations. (see attached) The problem appears to be that the nearest feature transform is using Manhattan distances to find the initial seam. Certain image orientations cause this to give very bad initial seams. A quick test of switching enblend to use Euclidean distances resolved this problem. To manage notifications about this bug go to: https://bugs.launchpad.net/enblend/+bug/739057/+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 989908] Re: black lines from graph-cut seam generator
** Changed in: enblend Status: New = Incomplete -- You received this bug notification because you are a member of Hugin Developers, which is subscribed to Enblend. https://bugs.launchpad.net/bugs/989908 Title: black lines from graph-cut seam generator Status in Enblend: Incomplete Bug description: Using enblend 4.1-e378b04ea3b7 I'm seeing black seam lines when the graph-cut seam generator is used. When I switch to use the nearest- feature-transform seam generator they go away. It's a large stitch involving 13 images. You can see the difference between the outputs here: http://www.bluelavalamp.net/hugin/enblend-seam/gc-pano_exposure_0006-small.jpg http://www.bluelavalamp.net/hugin/enblend-seam/psm-nft-pano_exposure_0006-small.jpg To manage notifications about this bug go to: https://bugs.launchpad.net/enblend/+bug/989908/+subscriptions ___ Mailing list: https://launchpad.net/~hugin-devs Post to : hugin-devs@lists.launchpad.net Unsubscribe : https://launchpad.net/~hugin-devs More help : https://help.launchpad.net/ListHelp
[Hugin-devs] [Bug 685105] Re: enblend fails to blend large pano
** Changed in: enblend Status: Confirmed = Fix Committed -- You received this bug notification because you are a member of Hugin Developers, which is subscribed to Enblend. https://bugs.launchpad.net/bugs/685105 Title: enblend fails to blend large pano Status in Enblend: Fix Committed Bug description: Enblend failed with: enblend --compression=LZW -m 1200 -w -f135659x3947+0+1091 -o pano8110_l.tif ... enblend: info: loading next image: pano8110_l.tif 1/1 enblend: out of memory enblend: std::bad_alloc This is a simple 0.5Gpixel panorama I shot. And agreed, Hugin did warn me that it might take a lot of memory. The thing is: There is no other tool to stitch this with, so I'll have to make do with hugin and its toolset I thought there was an imagecache that would swap parts of images to disk... To manage notifications about this bug go to: https://bugs.launchpad.net/enblend/+bug/685105/+subscriptions ___ Mailing list: https://launchpad.net/~hugin-devs Post to : hugin-devs@lists.launchpad.net Unsubscribe : https://launchpad.net/~hugin-devs More help : https://help.launchpad.net/ListHelp
[Hugin-devs] [Bug 989908] Re: black lines from graph-cut seam generator
THX keafert for trying out Enblend on large panos. You have convinced me that we can close this issue, because enblend fails to blend large pano is not a bug in the program. You proved that it is plain user incompetence, using wanna-be O/Ss, or, in summary nothing we can fix. The sizes of more than 236MPixels and more than 926MPixels respectively that you reported for your successful, final panos are well inside our design goals. - The black line artifacts are gone w/non-ImageCache versions. Issue #989908 may be unaffected, though. - The black hole artifacts are covered by issue #721136. I wish we had a not a bug status in LP. Do you want me to set it to Invalid or Won't fix? I'd prefer Invalid after all of your investigations. -- You received this bug notification because you are a member of Hugin Developers, which is subscribed to Enblend. https://bugs.launchpad.net/bugs/989908 Title: black lines from graph-cut seam generator Status in Enblend: New Bug description: Using enblend 4.1-e378b04ea3b7 I'm seeing black seam lines when the graph-cut seam generator is used. When I switch to use the nearest- feature-transform seam generator they go away. It's a large stitch involving 13 images. You can see the difference between the outputs here: http://www.bluelavalamp.net/hugin/enblend-seam/gc-pano_exposure_0006-small.jpg http://www.bluelavalamp.net/hugin/enblend-seam/psm-nft-pano_exposure_0006-small.jpg To manage notifications about this bug go to: https://bugs.launchpad.net/enblend/+bug/989908/+subscriptions ___ Mailing list: https://launchpad.net/~hugin-devs Post to : hugin-devs@lists.launchpad.net Unsubscribe : https://launchpad.net/~hugin-devs More help : https://help.launchpad.net/ListHelp
[Hugin-devs] [Bug 685105] Re: enblend fails to blend large pano
THX kaefert for trying out Enblend on large panos. You have convinced me that we can close this issue, because enblend fails to blend large pano is not a bug in the program. You proved that it is plain user incompetence, using wanna-be O/Ss, or, in summary nothing we can fix. The sizes of more than 236MPixels and more than 926MPixels respectively that you reported for your successful, final panos are well inside our design goals. - The black line artifacts are gone w/non-ImageCache versions. Issue #989908 may be unaffected, though. - The black hole artifacts are covered by issue #721136. I wish we had a not a bug status in LP. I'd prefer Invalid after all of your investigations. -- You received this bug notification because you are a member of Hugin Developers, which is subscribed to Enblend. https://bugs.launchpad.net/bugs/685105 Title: enblend fails to blend large pano Status in Enblend: Confirmed Bug description: Enblend failed with: enblend --compression=LZW -m 1200 -w -f135659x3947+0+1091 -o pano8110_l.tif ... enblend: info: loading next image: pano8110_l.tif 1/1 enblend: out of memory enblend: std::bad_alloc This is a simple 0.5Gpixel panorama I shot. And agreed, Hugin did warn me that it might take a lot of memory. The thing is: There is no other tool to stitch this with, so I'll have to make do with hugin and its toolset I thought there was an imagecache that would swap parts of images to disk... To manage notifications about this bug go to: https://bugs.launchpad.net/enblend/+bug/685105/+subscriptions ___ Mailing list: https://launchpad.net/~hugin-devs Post to : hugin-devs@lists.launchpad.net Unsubscribe : https://launchpad.net/~hugin-devs More help : https://help.launchpad.net/ListHelp
[Hugin-devs] [Bug 1193872] Re: Invariant violation! connected components: Need more labels than can be represented in the destination type.
** Changed in: enblend Assignee: (unassigned) = Mikolaj Leszczynski (rosomack) ** Changed in: enblend Status: New = In Progress ** Changed in: enblend Importance: Undecided = Medium -- You received this bug notification because you are a member of Hugin Developers, which is subscribed to Enblend. https://bugs.launchpad.net/bugs/1193872 Title: Invariant violation! connected components: Need more labels than can be represented in the destination type. Status in Enblend: In Progress Bug description: See attached file To manage notifications about this bug go to: https://bugs.launchpad.net/enblend/+bug/1193872/+subscriptions ___ Mailing list: https://launchpad.net/~hugin-devs Post to : hugin-devs@lists.launchpad.net Unsubscribe : https://launchpad.net/~hugin-devs More help : https://help.launchpad.net/ListHelp
[Hugin-devs] [Bug 1228601] Re: Emblend Error Minimizer1D
Fixed in 4.1.2. ** Changed in: enblend Status: New = Fix Released ** Changed in: enblend Importance: Undecided = Medium ** Changed in: enblend Assignee: (unassigned) = Christoph Spiel (cspiel) -- You received this bug notification because you are a member of Hugin Developers, which is subscribed to Enblend. https://bugs.launchpad.net/bugs/1228601 Title: Emblend Error Minimizer1D Status in Enblend: Fix Released Bug description: enblend: an exception occured enblend: Minimizer1D::set_bracket: minimum not bracketed enblend: info: remove invalid output image IMG_0700-hdr-IMG_0826-hdr.jpg make: *** [IMG_0700-hdr-IMG_0826-hdr.jpg] Error 1 I've gotten this error a few times and can find no info on either Minimizer1D or 'minimum not bracketed'. Restitching this panorama results in the same error. Two other projects with the same error can reliably reproduce the error when rerun. ### System Info: Operating System: Linux 3.10.9-200.fc19.x86_64 x86_64 Architecture: 64 bit Free memory: 27292300 kiB Hugin Version: 2012.0.0.a94faa15c927 Path to resources: /usr/share/hugin/xrc/ Path to data: /usr/share/hugin/data/ Path to user lensfun database: /home/drew/.local/share/lensfun Libraries wxWidgets: 2.8.12.0 libpano13: 2.9.18 Boost: 1.53.0 Exiv2: 0.23.0 To manage notifications about this bug go to: https://bugs.launchpad.net/enblend/+bug/1228601/+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 1214004] Re: Enfuse 4.1.1 crashes on Windows 7
There you go: fixed in 4.1.2, i.e. rev ac3dd60b8c45. ** Changed in: enblend Status: Fix Committed = Fix Released -- You received this bug notification because you are a member of Hugin Developers, which is subscribed to Enblend. https://bugs.launchpad.net/bugs/1214004 Title: Enfuse 4.1.1 crashes on Windows 7 Status in Enblend: Fix Released Bug description: When I try to enfuse the attached three images, Windows reports an error message on the following enfuse command: enfuse.exe -o DSC01374_HDR.tif --exposure-weight=1 --saturation- weight=0.2 --contrast-weight=0 --contrast-window-size=5 --depth=16 --compression=LZW aligned_.tif aligned_0001.tif aligned_0002.tif This is the error message: [Window Title] enfuse.exe [Main Instruction] enfuse.exe has stopped working [Content] A problem caused the program to stop working correctly. Windows will close the program and notify you if a solution is available. [Close program] I tried to attach the three images to this bug report, but I guess the file is too large (500 MB). If you want, I can make it available to you. I'm running enblend-enfuse-4.1.1-win64 on Windows 7. To manage notifications about this bug go to: https://bugs.launchpad.net/enblend/+bug/1214004/+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 1214004] Re: Enfuse 4.1.1 crashes on Windows 7
The problem is the escaping exception Minimizer1D::set_bracket: minimum not bracketed. It was fixed in rev0f3c8eea75a2, which belongs to the current development series; the patch has not been backported to the stable series yet, i.e it is currently unreleased. http://hg.code.sf.net/p/enblend/code/rev/0f3c8eea75a2 As it is unsure whether we'll ship another stable release before the development line officially becomes version 4.2, you can try to get your hands on any binary built with the mentioned mid-May 2013 fix. ** Changed in: enblend Status: Incomplete = Fix Committed ** Changed in: enblend Importance: Undecided = Medium ** Changed in: enblend Assignee: (unassigned) = Christoph Spiel (cspiel) -- You received this bug notification because you are a member of Hugin Developers, which is subscribed to Enblend. https://bugs.launchpad.net/bugs/1214004 Title: Enfuse 4.1.1 crashes on Windows 7 Status in Enblend: Fix Committed Bug description: When I try to enfuse the attached three images, Windows reports an error message on the following enfuse command: enfuse.exe -o DSC01374_HDR.tif --exposure-weight=1 --saturation- weight=0.2 --contrast-weight=0 --contrast-window-size=5 --depth=16 --compression=LZW aligned_.tif aligned_0001.tif aligned_0002.tif This is the error message: [Window Title] enfuse.exe [Main Instruction] enfuse.exe has stopped working [Content] A problem caused the program to stop working correctly. Windows will close the program and notify you if a solution is available. [Close program] I tried to attach the three images to this bug report, but I guess the file is too large (500 MB). If you want, I can make it available to you. I'm running enblend-enfuse-4.1.1-win64 on Windows 7. To manage notifications about this bug go to: https://bugs.launchpad.net/enblend/+bug/1214004/+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 1214004] Re: Enfuse 4.1.1 crashes on Windows 7
(1) You could re-run Enfuse with a higher verbosity setting. See the Enfuse manual for a description of the levels. (2) You could re-run Enfuse under the supervision of a debugger. Keep your fingers crossed that your binary contains (enough) debugging symbols. This should give us more insights than just something is rotten, Marcellus. -- You received this bug notification because you are a member of Hugin Developers, which is subscribed to Enblend. https://bugs.launchpad.net/bugs/1214004 Title: Enfuse 4.1.1 crashes on Windows 7 Status in Enblend: Incomplete Bug description: When I try to enfuse the attached three images, Windows reports an error message on the following enfuse command: enfuse.exe -o DSC01374_HDR.tif --exposure-weight=1 --saturation- weight=0.2 --contrast-weight=0 --contrast-window-size=5 --depth=16 --compression=LZW aligned_.tif aligned_0001.tif aligned_0002.tif This is the error message: [Window Title] enfuse.exe [Main Instruction] enfuse.exe has stopped working [Content] A problem caused the program to stop working correctly. Windows will close the program and notify you if a solution is available. [Close program] I tried to attach the three images to this bug report, but I guess the file is too large (500 MB). If you want, I can make it available to you. I'm running enblend-enfuse-4.1.1-win64 on Windows 7. To manage notifications about this bug go to: https://bugs.launchpad.net/enblend/+bug/1214004/+subscriptions ___ Mailing list: https://launchpad.net/~hugin-devs Post to : hugin-devs@lists.launchpad.net Unsubscribe : https://launchpad.net/~hugin-devs More help : https://help.launchpad.net/ListHelp
[Hugin-devs] [Bug 685105] Re: enblend fails to blend large pano
Oops! Sorry, I was off-by-one in the exponent. 8-/ The largest _signed_ integer (`int') typically is 2**31 - 1, not 2**32 - 1. The latter is correct for _unsigned_ integers (`unsigned int'). However, your calculation still holds even with the half-as-large limit. Another thing that would be great for that purpose was if I could combine pictures of different zoom levels into a panorama with hugin. Enblend will always produce an image (often called panorama) at exactly one resolution. Currently, no provisions are available to generate data for multi-resolution panorama viewers. A common way to circumvent this limitation is to generate a panorama at the highest possible resolution and feed it into a 3D, VR, or whatever multi-resolution format generator, which -- again typically -- has compatible viewer applications as side-kicks or vice versa. With respect to the problem of combining images at different resolutions into one panorama. This is possible in the way that you could upscale all of your wide-angle shots until their resolution matches the one of your most extreme telephoto image. Now you cut holes with some overlap (for control-points, alignment and for Enblend to blend the seam away) into the wide-angle shots where the telephoto ones sit. Otherwise Enblend complains that your telephoto images do not add new content. Finally, you blend all images together, where you pay particular attention to the images' order. Wide-angle shots -- the frames -- go first, telephoto ones -- the pot-hole fillers -- go last. I have never created a panorama this way, but we have a standard test case for Enblend comprising of a pair of images, where the first image has a hole and the second one fills it with generous overlap. This test works perfectly well. Maybe, Bruno Postle wants to chime in here, as he often experiments with the boundaries of Enblend. With hugin 2012 the assistant finds a lot of wrong control points between pictures that don't overlap. ... This question ought to go to the Hugin newsgroup. It is misplaced here. -- You received this bug notification because you are a member of Hugin Developers, which is subscribed to Enblend. https://bugs.launchpad.net/bugs/685105 Title: enblend fails to blend large pano Status in Enblend: Confirmed Bug description: Enblend failed with: enblend --compression=LZW -m 1200 -w -f135659x3947+0+1091 -o pano8110_l.tif ... enblend: info: loading next image: pano8110_l.tif 1/1 enblend: out of memory enblend: std::bad_alloc This is a simple 0.5Gpixel panorama I shot. And agreed, Hugin did warn me that it might take a lot of memory. The thing is: There is no other tool to stitch this with, so I'll have to make do with hugin and its toolset I thought there was an imagecache that would swap parts of images to disk... To manage notifications about this bug go to: https://bugs.launchpad.net/enblend/+bug/685105/+subscriptions ___ Mailing list: https://launchpad.net/~hugin-devs Post to : hugin-devs@lists.launchpad.net Unsubscribe : https://launchpad.net/~hugin-devs More help : https://help.launchpad.net/ListHelp
[Hugin-devs] [Bug 1228601] Re: Emblend Error Minimizer1D
Try tip of development branch. -- You received this bug notification because you are a member of Hugin Developers, which is subscribed to Enblend. https://bugs.launchpad.net/bugs/1228601 Title: Emblend Error Minimizer1D Status in Enblend: New Bug description: enblend: an exception occured enblend: Minimizer1D::set_bracket: minimum not bracketed enblend: info: remove invalid output image IMG_0700-hdr-IMG_0826-hdr.jpg make: *** [IMG_0700-hdr-IMG_0826-hdr.jpg] Error 1 I've gotten this error a few times and can find no info on either Minimizer1D or 'minimum not bracketed'. Restitching this panorama results in the same error. Two other projects with the same error can reliably reproduce the error when rerun. ### System Info: Operating System: Linux 3.10.9-200.fc19.x86_64 x86_64 Architecture: 64 bit Free memory: 27292300 kiB Hugin Version: 2012.0.0.a94faa15c927 Path to resources: /usr/share/hugin/xrc/ Path to data: /usr/share/hugin/data/ Path to user lensfun database: /home/drew/.local/share/lensfun Libraries wxWidgets: 2.8.12.0 libpano13: 2.9.18 Boost: 1.53.0 Exiv2: 0.23.0 To manage notifications about this bug go to: https://bugs.launchpad.net/enblend/+bug/1228601/+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 1220051] Re: crash of enblend due to malloc failure while exporting to exr file
Read your own log file and you find Enblend's comment: enblend: warning: only one input image given. enblend: warning: Enblend needs two or more overlapping input images in order to do enblend: warning: blending calculations. The output will be the same as the input. which is correct as you just pass Montan-2013-2845-48_stack_hdr_.exr to Enblend. I guess you wanted to pass all three of your images, didn't you? The following error is unfortunate, but you would not have created any panorama anyhow. Follow up here if _this_ error re-appears. -- You received this bug notification because you are a member of Hugin Developers, which is subscribed to Enblend. https://bugs.launchpad.net/bugs/1220051 Title: crash of enblend due to malloc failure while exporting to exr file Status in Enblend: New Bug description: please have a look at my log file To manage notifications about this bug go to: https://bugs.launchpad.net/enblend/+bug/1220051/+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 1220523] Re: enblend: error writing to image swap file.
You ran out of disk space. Perhaps the partion where /tmp gets mounted is small. The particular version of Enblend you are using (ImageCache) is best for systems with little memory, but lots of free disk space. Prefer the version without ImageCache to benefit from lots of RAM. ** Changed in: enblend Status: New = Invalid -- You received this bug notification because you are a member of Hugin Developers, which is subscribed to Enblend. https://bugs.launchpad.net/bugs/1220523 Title: enblend: error writing to image swap file. Status in Enblend: Invalid Bug description: Getting an error when stitching about memory/swap file. I have LOTS of memory left. Text of the logfile: --- === *** Panorama makefile generated by Hugin *** === System information === Operating system: GNU/Linux Release: 3.10.10-1-ARCH Kernel version: #1 SMP PREEMPT Fri Aug 30 11:30:06 CEST 2013 Machine: x86_64 Disc usage Filesystem Size Used Avail Use% Mounted on /dev/sda1 220G 102G 107G 49% / dev 1.9G 0 1.9G 0% /dev run 2.0G 960K 2.0G 1% /run tmpfs 2.0G 604K 2.0G 1% /dev/shm tmpfs 2.0G 0 2.0G 0% /sys/fs/cgroup tmpfs 2.0G 64K 2.0G 1% /tmp /dev/sdb1 275G 201G 61G 77% /media/Storage /dev/sdc1 917G 448G 423G 52% /media/Storage2 /dev/sdd1 7.5G 224K 7.5G 1% /run/media/sam/CANON_DC /dev/sde115G 1.4G 14G 10% /run/media/sam/disk Memory usage total used free sharedbuffers cached Mem: 3957 1690 2266 0 11357 -/+ buffers/cache: 1321 2635 Swap:10485745 9740 === Output options === Hugin Version: 2012.0.0.a94faa15c927 Project file: /tmp/huginpto_HiFrJn Output prefix: IMGP6318p Projection: Equirectangular (2) Field of view: 137 x 62 Canvas dimensions: 23440 x 10608 Crop area: (684,926) - (21872,8222) Output exposure value: -0.46 Selected outputs Normal panorama * Blended panorama === Input images === Number of images in project file: 6 Number of active images: 6 Image 0: /home/sam/Desktop/Slesse/converted/IMGP6318.png Image 0: Size 3032x2016, Exposure: -0.46 Image 1: /home/sam/Desktop/Slesse/converted/IMGP6319.png Image 1: Size 3032x2016, Exposure: -0.46 Image 2: /home/sam/Desktop/Slesse/converted/IMGP6320.png Image 2: Size 3032x2016, Exposure: -0.46 Image 3: /home/sam/Desktop/Slesse/converted/IMGP6321.png Image 3: Size 3032x2016, Exposure: -0.46 Image 4: /home/sam/Desktop/Slesse/converted/IMGP6322.png Image 4: Size 3032x2016, Exposure: -0.46 Image 5: /home/sam/Desktop/Slesse/converted/IMGP6323.png Image 5: Size 3032x2016, Exposure: -0.46 === Testing programs === Checking nona...[OK] Checking enblend...[OK] Checking enfuse...[OK] Checking hugin_hdrmerge...[OK] Checking exiftool...[OK] === Stitching panorama === nona -t 4 -r ldr -m TIFF_m -o IMGP6318p -i 0 /tmp/huginpto_HiFrJn Unable to read EXIF data from opened file:/home/sam/Desktop/Slesse/converted/IMGP6318.png Unable to read EXIF data from opened file:/home/sam/Desktop/Slesse/converted/IMGP6319.png Unable to read EXIF data from opened file:/home/sam/Desktop/Slesse/converted/IMGP6320.png Unable to read EXIF data from opened file:/home/sam/Desktop/Slesse/converted/IMGP6321.png Unable to read EXIF data from opened file:/home/sam/Desktop/Slesse/converted/IMGP6322.png Unable to read EXIF data from opened file:/home/sam/Desktop/Slesse/converted/IMGP6323.png nona -t 4 -r ldr -m TIFF_m -o IMGP6318p -i 1 /tmp/huginpto_HiFrJn Unable to read EXIF data from opened file:/home/sam/Desktop/Slesse/converted/IMGP6318.png Unable to read EXIF data from opened file:/home/sam/Desktop/Slesse/converted/IMGP6319.png Unable to read EXIF data from opened file:/home/sam/Desktop/Slesse/converted/IMGP6320.png Unable to read EXIF data from opened file:/home/sam/Desktop/Slesse/converted/IMGP6321.png Unable to read EXIF data from opened
[Hugin-devs] [Bug 1214004] Re: Enfuse 4.1.1 crashes on Windows 7
We can't smell error messages. You must show them to us in the Bug Description. ** Changed in: enblend Status: New = Incomplete -- You received this bug notification because you are a member of Hugin Developers, which is subscribed to Enblend. https://bugs.launchpad.net/bugs/1214004 Title: Enfuse 4.1.1 crashes on Windows 7 Status in Enblend: Incomplete Bug description: When I try to enfuse the attached three images, Windows reports an error message on the following enfuse command: enfuse.exe -o DSC01374_HDR.tif --exposure-weight=1 --saturation- weight=0.2 --contrast-weight=0 --contrast-window-size=5 --depth=16 --compression=LZW aligned_.tif aligned_0001.tif aligned_0002.tif I tried to attach the three images to this bug report, but I guess the file is too large (500 MB). If you want, I can make it available to you. I'm running enblend-enfuse-4.1.1-win64 on Windows 7. To manage notifications about this bug go to: https://bugs.launchpad.net/enblend/+bug/1214004/+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 1220886] Re: imagemagick used to build docs but fatal if not found with docs disabled
** Changed in: enblend Status: New = Fix Committed ** Changed in: enblend Importance: Undecided = Medium ** Changed in: enblend Assignee: (unassigned) = Kornel (kornel-benko) -- You received this bug notification because you are a member of Hugin Developers, which is subscribed to Enblend. https://bugs.launchpad.net/bugs/1220886 Title: imagemagick used to build docs but fatal if not found with docs disabled Status in Enblend: Fix Committed Bug description: According to the README, ImageMagick is used for building the documentation. However, the ImageMagick check in CMakeLists.txt is fatal even if -DDOC=OFF is used. If there is no other use of the ImageMagick tools inside enblend- enfuse, the ImageMagick test should not happen unless -DDOC=ON. To manage notifications about this bug go to: https://bugs.launchpad.net/enblend/+bug/1220886/+subscriptions ___ Mailing list: https://launchpad.net/~hugin-devs Post to : hugin-devs@lists.launchpad.net Unsubscribe : https://launchpad.net/~hugin-devs More help : https://help.launchpad.net/ListHelp
[Hugin-devs] [Bug 685105] Re: enblend fails to blend large pano
OK -- a few words from your chief maintainer of Enblend/Enfuse. 1. ImageCache Any ImageCache support has been removed from the development branches of Enblend and Enfuse. It won't come back unless some brave, brilliant, ... hacker steps up and takes responsibility for the code. Thus, I consider comments on whether to use or to avoid the ImageCache as futile. Virtually, only the non-ImageCache (inherently fast and easily parallelizable) version exists. 2. Image-Size Limitations of Enblend and Enfuse In brief: there are several. Some restrictions exist because we are a bit too generous in our use of memory, others are enforced upon us by third-party libraries, most importantly Vigra. Rule-of-Thumb: Neither Enblend no Enfuse can handle any image larger than 2**32 - 1 pixels. For geeks this is INT_MAX or std::numeric_limitsint::max(). * The type of image (8-bit, 16-bit, bw, color, w/alpha, etc.) does not matter here, only the pixel count. * The limit applies to any of the input images, all internally-held, transient images, and of course the output image. As a programmer would put it: Vigra sometimes substitutes type `int' for type `ptrdiff_t' and that bleeds through. * Working with a 64-bit o/s does not automatically help, for many compilers encode `int' with 32 bits to improve performance; they only use 64 bits for type `long int'. Just compiling Enblend or Enfuse with a C++-compiler that uses 64 bits for an `int' on such systems, breaks the ABI, i.e., the resulting objects won't link against any of the support libraries. -- You received this bug notification because you are a member of Hugin Developers, which is subscribed to Enblend. https://bugs.launchpad.net/bugs/685105 Title: enblend fails to blend large pano Status in Enblend: Confirmed Bug description: Enblend failed with: enblend --compression=LZW -m 1200 -w -f135659x3947+0+1091 -o pano8110_l.tif ... enblend: info: loading next image: pano8110_l.tif 1/1 enblend: out of memory enblend: std::bad_alloc This is a simple 0.5Gpixel panorama I shot. And agreed, Hugin did warn me that it might take a lot of memory. The thing is: There is no other tool to stitch this with, so I'll have to make do with hugin and its toolset I thought there was an imagecache that would swap parts of images to disk... To manage notifications about this bug go to: https://bugs.launchpad.net/enblend/+bug/685105/+subscriptions ___ Mailing list: https://launchpad.net/~hugin-devs Post to : hugin-devs@lists.launchpad.net Unsubscribe : https://launchpad.net/~hugin-devs More help : https://help.launchpad.net/ListHelp
[Hugin-devs] [Bug 1220051] Re: crash of enblend due to malloc failure while exporting to exr file
Martha, my dear - You are right, I cannot reproduce the problem here on any of my (Debian/SuSE) Linux boxes. If EXR is your only problem, I can suggest to you that you switch to 16-bit TIFF, 16-bit PNG, or 32-bit floating-point TIFF. EXR's `half' float suffers from a short significant anyhow. See the description of the `--depth' option in any Enblend or Enfuse manual. Either tell nona(1) to produce appropriate images or convert manually with ImageMagick, GraphicsMagick, G'Mic or whatever. /Surely -- You received this bug notification because you are a member of Hugin Developers, which is subscribed to Enblend. https://bugs.launchpad.net/bugs/1220051 Title: crash of enblend due to malloc failure while exporting to exr file Status in Enblend: New Bug description: please have a look at my log file To manage notifications about this bug go to: https://bugs.launchpad.net/enblend/+bug/1220051/+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] Re: autoconf doesn't support arm 64
You can just bump the version forward. Please adjust configure.in accordingly. Patch is candidate for 4.1.2. ** Changed in: enblend Status: New = Triaged ** Changed in: enblend Importance: Undecided = Medium -- 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: Triaged 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 1181678] Re: build-error with texinfo 5.1
THX for tracking down the problems in detail.
#1: Patch in my local repo; probably will be applied.
#2: Screwing up the output is not the way to go. We can
prevent unwanted whitespace from occurring by terminating
the relevant lines with `@c', though:
@classictimes{}@c
thereby violating your rule ... line by itself.
#3: Breaks my build -- LOL.
$ makeinfo --version
makeinfo (GNU texinfo) 4.13
** Changed in: enblend
Status: New = Triaged
** Changed in: enblend
Importance: Undecided = Low
--
You received this bug notification because you are a member of Hugin
Developers, which is subscribed to Enblend.
https://bugs.launchpad.net/bugs/1181678
Title:
build-error with texinfo 5.1
Status in Enblend:
Triaged
Bug description:
Hello,
documentation generation fails with texinfo 5.1. texinfo seems to have
stopped supporting colons in variable names (@set - @value), causing errors
like this one:
-
doc/enfuse.texi:564: bad syntax for @value
-
According to texinfo 5.1 documentation basically the only thing
guaranteed to work are alpha-numericals:
Subsequent characters, if any, may not be whitespace, ‘@’, braces,
angle brackets, or any of ‘~`^+|’; other characters, such as ‘%’, may
work. However, it is best to use only letters and numerals in a flag
name, not ‘-’ or ‘_’ or others—they will work in some contexts, but
not all, due to limitations in TeX.
cu Andreas
See http://bugs.debian.org/708800 or
https://bugzilla.redhat.com/show_bug.cgi?id=919935
To manage notifications about this bug go to:
https://bugs.launchpad.net/enblend/+bug/1181678/+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 1181678] Re: build-error with texinfo 5.1
THX for feeding the doc into Texinfo-5.1 again. I'm still on makeinfo-4.13, so I cannot check myself yet. Thus, the problem will remain unless someone sends us a patch. On a medium time-scale I'm inclined to switch to plain LaTeX and drop Texinfo. The vast majority of users doesn't read the documentation at all. The rest prefers PDF. Or whatever HTML, if it only is on a public server. -- You received this bug notification because you are a member of Hugin Developers, which is subscribed to Enblend. https://bugs.launchpad.net/bugs/1181678 Title: build-error with texinfo 5.1 Status in Enblend: New Bug description: Hello, documentation generation fails with texinfo 5.1. texinfo seems to have stopped supporting colons in variable names (@set - @value), causing errors like this one: - doc/enfuse.texi:564: bad syntax for @value - According to texinfo 5.1 documentation basically the only thing guaranteed to work are alpha-numericals: Subsequent characters, if any, may not be whitespace, ‘@’, braces, angle brackets, or any of ‘~`^+|’; other characters, such as ‘%’, may work. However, it is best to use only letters and numerals in a flag name, not ‘-’ or ‘_’ or others—they will work in some contexts, but not all, due to limitations in TeX. cu Andreas See http://bugs.debian.org/708800 or https://bugzilla.redhat.com/show_bug.cgi?id=919935 To manage notifications about this bug go to: https://bugs.launchpad.net/enblend/+bug/1181678/+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] Re: build with texinfo 5.1
Can we set the status to Won't Fix or better Invalid? This looks like an Automake/Autoconf problem. -- 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: Triaged 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 1155350] Re: build with texinfo 5.1
** Changed in: enblend Status: New = Triaged -- 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: Triaged 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 1155350] Re: build with texinfo 5.1
The patch is nonsense because all Makefile.ins are re-generated by every run of configure(1). -- 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 1153546] Re: black artifacts after blending
Please work on the _tips_ of either the development branch (currently: http://hg.code.sf.net/p/enblend/code/rev/b0b27f8c7de1) or the stable branch (currently: http://hg.code.sf.net/p/enblend/code/rev/881360218998), for your version is (i) ancient, i.e. we won't fix anything there anyhow and (ii) is _known_ to have a bug in the polygon closing pretty much like to one you are reporting. It was fixed in revisions #63725e0bd9ec (default) and #8a9faf211724 (stable-4_1). Don't hesitate to contact me via private e-mail, if you need assistance. -- You received this bug notification because you are a member of Hugin Developers, which is subscribed to Enblend. https://bugs.launchpad.net/bugs/1153546 Title: black artifacts after blending Status in Enblend: New Bug description: I'm frequently getting black artifacts on some blended photos (none or one in small projects, easily 5 to 10 artifacts in projects of more than 100 photos). The occurrence of artifacts does not depend on the output resolution. The shape, however, is dependent on the resolution. Appended are three photos. On my machine blending yields the following output: $ enblend -v -o foo.tif img_7306-7317.tif img_7306-73170010.tif img_7306-73170011.tif --fine-mask enblend: info: loading next image: img_7306-7317.tif 1/1 enblend: info: loading next image: img_7306-73170010.tif 1/1 enblend: images do not overlap - they will be combined without blending enblend: use the -l flag to force blending with a certain number of levels enblend: info: loading next image: img_7306-73170011.tif 1/1 enblend: info: creating fine blend mask: 1/3 2/3 3/3 enblend: info: optimizing 2 distinct seams enblend: info: Annealing Optimizer, s0: 1/4 2/4 3/4 4/4 enblend: info: Annealing Optimizer, s1: 1/4 2/4 3/4 4/4 enblend: info: Dijkstra Optimizer: s0 s1 enblend: info: using 5 blending level(s) enblend: info: generating Gaussian pyramid: g0 g1 g2 g3 g4 enblend: info: generating Gaussian pyramid: g0 g1 g2 g3 g4 enblend: info: generating Laplacian pyramid: l0 l1 l2 l3 l4 enblend: info: generating Gaussian pyramid: g0 g1 g2 g3 g4 enblend: info: generating Laplacian pyramid: l0 l1 l2 l3 l4 enblend: info: blending layers: l0 l1 l2 l3 l4 enblend: info: collapsing Laplacian pyramid: l4 l3 l2 l1 l0 enblend: info: writing final output The version is $ enblend -V enblend 4.1-700e60bc31b5 Copyright (C) 2004-2012 Andrew Mihal. License GPLv2+: GNU GPL version 2 or later http://www.gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Written by Andrew Mihal and others. Please tell me if any additional output would be helpful. cheers, lukas To manage notifications about this bug go to: https://bugs.launchpad.net/enblend/+bug/1153546/+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 1153546] Re: black artifacts after blending
... choosing nft doesn't make a difference with respect to my problem You are using a pre-release of Enblend version 4.1. Therefore, your default PSG is NFT, I'm on the development tip and GC is the default here, thus I had to force NFT and you found no differences. Makes sense. Would it be a solution for me to turn seam-optimization off by default? Yes, if it cures the problem and you can live with the sub-optimal blend. We have a bug in the seam-line optimizer in Enblend version 4.1. You could either reconfigure your SCM to use the stable branch with hg branch stable-4_1 or download the 4.1pl1 tarball from SF. BTW, Both go with the old Boost libraries. Is there anything I can do to find out what what causes my black areas? Depends on how masochistic you are. If the packaged version 4.1.1 or switching to the stable branch fixes the bug you could call it a day. Otherwise, use e.g. `--save-masks' or `--optimize --visualize' to find out about the seam lines. More hard core hacking (We'll take the long way. -- Princess Amidala): recompile Enblend with -DDEBUG_POLYGON_FILL after comprehending what the #define does and where the the heck ,polygon.tif comes from. Unfortunately I can't compile the most recent version off the svn because it depends on some boost libraries that are newer than the ones that ship with Debian 6. However Debian 7 will be stable some time soon-isch. I'm on an ancient Debian system, too. My workaround is to pull Boost from their SVN repo, compile it, and point to the in-source-tree directories b2 instructs me to when re-configuring Enblend/Enfuse. Part of my reconfigure script looks something like this: set -a# export all variables ... BOOST_ROOT=path-to-compiled-boost-svn-directory CPPFLAGS=-I$BOOST_ROOT LDFLAGS=-L$BOOST_ROOT/stage/lib -Wl,-rpath=$BOOST_ROOT/stage/lib ... ../configure your-options -- You received this bug notification because you are a member of Hugin Developers, which is subscribed to Enblend. https://bugs.launchpad.net/bugs/1153546 Title: black artifacts after blending Status in Enblend: New Bug description: I'm frequently getting black artifacts on some blended photos (none or one in small projects, easily 5 to 10 artifacts in projects of more than 100 photos). The occurrence of artifacts does not depend on the output resolution. The shape, however, is dependent on the resolution. Appended are three photos. On my machine blending yields the following output: $ enblend -v -o foo.tif img_7306-7317.tif img_7306-73170010.tif img_7306-73170011.tif --fine-mask enblend: info: loading next image: img_7306-7317.tif 1/1 enblend: info: loading next image: img_7306-73170010.tif 1/1 enblend: images do not overlap - they will be combined without blending enblend: use the -l flag to force blending with a certain number of levels enblend: info: loading next image: img_7306-73170011.tif 1/1 enblend: info: creating fine blend mask: 1/3 2/3 3/3 enblend: info: optimizing 2 distinct seams enblend: info: Annealing Optimizer, s0: 1/4 2/4 3/4 4/4 enblend: info: Annealing Optimizer, s1: 1/4 2/4 3/4 4/4 enblend: info: Dijkstra Optimizer: s0 s1 enblend: info: using 5 blending level(s) enblend: info: generating Gaussian pyramid: g0 g1 g2 g3 g4 enblend: info: generating Gaussian pyramid: g0 g1 g2 g3 g4 enblend: info: generating Laplacian pyramid: l0 l1 l2 l3 l4 enblend: info: generating Gaussian pyramid: g0 g1 g2 g3 g4 enblend: info: generating Laplacian pyramid: l0 l1 l2 l3 l4 enblend: info: blending layers: l0 l1 l2 l3 l4 enblend: info: collapsing Laplacian pyramid: l4 l3 l2 l1 l0 enblend: info: writing final output The version is $ enblend -V enblend 4.1-700e60bc31b5 Copyright (C) 2004-2012 Andrew Mihal. License GPLv2+: GNU GPL version 2 or later http://www.gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Written by Andrew Mihal and others. Please tell me if any additional output would be helpful. cheers, lukas To manage notifications about this bug go to: https://bugs.launchpad.net/enblend/+bug/1153546/+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 1153546] Re: black artifacts after blending
** Attachment added: Enblend output image https://bugs.launchpad.net/enblend/+bug/1153546/+attachment/3568485/+files/a.tif -- You received this bug notification because you are a member of Hugin Developers, which is subscribed to Enblend. https://bugs.launchpad.net/bugs/1153546 Title: black artifacts after blending Status in Enblend: New Bug description: I'm frequently getting black artifacts on some blended photos (none or one in small projects, easily 5 to 10 artifacts in projects of more than 100 photos). The occurrence of artifacts does not depend on the output resolution. The shape, however, is dependent on the resolution. Appended are three photos. On my machine blending yields the following output: $ enblend -v -o foo.tif img_7306-7317.tif img_7306-73170010.tif img_7306-73170011.tif --fine-mask enblend: info: loading next image: img_7306-7317.tif 1/1 enblend: info: loading next image: img_7306-73170010.tif 1/1 enblend: images do not overlap - they will be combined without blending enblend: use the -l flag to force blending with a certain number of levels enblend: info: loading next image: img_7306-73170011.tif 1/1 enblend: info: creating fine blend mask: 1/3 2/3 3/3 enblend: info: optimizing 2 distinct seams enblend: info: Annealing Optimizer, s0: 1/4 2/4 3/4 4/4 enblend: info: Annealing Optimizer, s1: 1/4 2/4 3/4 4/4 enblend: info: Dijkstra Optimizer: s0 s1 enblend: info: using 5 blending level(s) enblend: info: generating Gaussian pyramid: g0 g1 g2 g3 g4 enblend: info: generating Gaussian pyramid: g0 g1 g2 g3 g4 enblend: info: generating Laplacian pyramid: l0 l1 l2 l3 l4 enblend: info: generating Gaussian pyramid: g0 g1 g2 g3 g4 enblend: info: generating Laplacian pyramid: l0 l1 l2 l3 l4 enblend: info: blending layers: l0 l1 l2 l3 l4 enblend: info: collapsing Laplacian pyramid: l4 l3 l2 l1 l0 enblend: info: writing final output The version is $ enblend -V enblend 4.1-700e60bc31b5 Copyright (C) 2004-2012 Andrew Mihal. License GPLv2+: GNU GPL version 2 or later http://www.gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Written by Andrew Mihal and others. Please tell me if any additional output would be helpful. cheers, lukas To manage notifications about this bug go to: https://bugs.launchpad.net/enblend/+bug/1153546/+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
