[Hugin-devs] [Bug 721136] Re: enblend creates an unexplainable black area.
just for traceability (especially since this bug seems to still be present [I did not check it myself, just inferring from the bug status]) To explain my comments I've used a few links to pictures hosted on my own NAS reachable through a dyn-dns domain, which is no longer available because they canceled their free services. You can still find the images by replacing the domain kaefert.is-a-geek.org by either koega.no-ip.org or nas.koelbl15.wien.funkfeuer.at So for example for the image in my comment above this one: http://koega.no-ip.org/misc/hugin/enblend-black-areas/Screenshot%20from%202014-01-30%201918_40.jpg http://nas.koelbl15.wien.funkfeuer.at/misc/hugin/enblend-black-areas/Screenshot%20from%202014-01-30%201918_40.jpg -- 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 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
