Fix for deprecation of omp_set_nested in OpenMP 5.0
Replace enum by static constexpr
Set minimum CMake version 3.12
Fixes compilation with new Visual Studio compiler
Disable some optimization debug statements
Accept also upper case and mixed case extensions
Write also canvas size to output files
Enfuse: Fixes parsing of entropy cutoff values from command line
Hi Christoph, Thanks for your suggestion. I will follow your advice! Marcin
I cannot assist you with problems related to Windows. Maybe you ask your questions in the Hugin newsgroup.
Hi, I hope not to bother you with my question but ever since EnfuseGui is my favoritue tool for an amateur photographer like me I decided to ask for an advice about the program. I have just updated my system from Windows 10 to 11 Pro and after that EnfuseGui stopped to enfuse and showing up the information: "Invalid Enfuse version found. EnfuseGuirequires version 4 or later". I have downloaded "enblend-enfuse-4.2-win64" but since I have found that is not an excutable file so I cannot install it I...
Improve comments, small non-functional refactoring steps
Clean up old algorithms
Switch to new algorithm
Introduce new functionality to generate segments of either seam lines or entry/exit points, and run graphcut on these. Keep the new algorithms disabled.
factor out two large functions: getInterPointList and graphcutSegments
functionality to find all seam line entry points
let processCutResults accept a vector of paths
factor out nearest edge function
switch several variables to being passed around as const ref instead of non-const pointers
pass around Circulators by value (removing a memory leak), other non-functional simplifications
Fixes writing of metadata
CMake: Update for newer OpenEXR versions
Hello, I'm interested in using a recent version of enblend that supports bigtiff and OpenCL/OpenMP, so I compiled it from source. But I would like there to be a broader release that my distro could package and everyone else could use. Obviously it's a volunteer FOSS project and the maintainers are busy, so I'm interested in sponsoring some work to get a stable public release made. Is there any mechanism set up for this? Would any of the maintainers be available to do this work if some money were...
Hello, I'm interested in using a recent version of enblend that supports bigtiff and OpenMP, so I compiled it from source. But I would like there to be a broader release that my distro could package and everyone else could use. Obviously it's a volunteer FOSS project and the maintainers are busy, so I'm interested in sponsoring some work to get a stable public release made. Is there any mechanism set up for this? Would any of the maintainers be available to do this work if some money were available?...
Hello, I'm interested in using a recent version of enblend that supports bigtiff and OpenCL, so I compiled it from source. But I would like there to be a broader release that my distro could package and everyone else could use. Obviously it's a volunteer FOSS project and the maintainers are busy, so I'm interested in sponsoring some work to get a stable public release made. Is there any mechanism set up for this? Would any of the maintainers be available to do this work if some money were available?...
Hello, I'm interested in using a recent version of enblend that supports bigtiff and OpenCL. I ran into some build errors and don't have time to troubleshoot it myself. I would like there to be a broader release that my distro could package and everyone else could use. Obviously it's a volunteer FOSS project and the maintainers are busy, so I'm interested in sponsoring some work to get a stable public release made. Is there any mechanism set up for this? Would any of the maintainers be available...
I also have a question that, I want to use my GPU for aceelerating the assisted control points because I have more than 150 images to stitich and here the updated version which I have downloaded shows me no gpu compilation of the enblend 4.2 version in the hugin. Could anyone help me regaring this?
Fixes compilation with musl libc with missing GLOB_BRACE [2056095]
Define variable later where needed
Added some const expressions
Add namespace to ceil
maskBounds: Slightly rearrange parameters to make return value more clear
Fixes typo
Use C++ standard header than older legacy xx.h includes
CMake: Fixes wrong bracket
Avoid small integer promotion
Avoid unnecessary warning
Correctly reset sum_ member
Avoid out of bounds pixels while blending
Refactored std::vector<MaskPyramidType*>* into own class
Allow building enblend with shared libraries (Windows only)
Remove wrong __attribute__
Fixes deprecated std::binary_function in C++17
Fixes deprecated std::unary_function in C++17
More fixes for FindOpenEXR in 3.x series
Fix encoding issues in documentation
Fixes typo in documentation
Update FindOpenEXR for version 3.x
Fixes a warning in CMake 3.22
Sorry for posting with "no subject". The initial post failed as I tried to attach the files directly (rather than link to them), and on the recreate I forgot to fill in the topic. Seems I can't change it retrospectively either.
Sorry for posting with "no topic". The initial post failed as I tried to attach the files directly (rather than link to them), and on the recreate I forgot to fill in the topic. Seems I can't change it retrospectively either.
I'm using enblend 4.2 for my panoramas, and recently ran into a strange issue. When I blend the two pictures from the archive at https://extra.domob.eu/enblend.tar.bz2 (a.tif and b.tif) without any options ("enblend -o output.tif a.tif b.tif"), the blended output is much lighter in the overlapping area than any of the two input images. I don't really understand how that can happen. Any hints as to why and how to work around it?
Catch exceptions by reference
Removed workaround for older boost version
Update FindOpenEXR for version 3.x
Fix for missing include with newer gcc versions [1889191]
Hi there! Can you clarify how you'd expect this option to slow things down? I'm seeing a drastic decrease in performance when I moved from Ubuntu 16.04 which I was able to do "-m 6144" to 20.04 which has removed this option. Please see attached graph where I compared a few options. Option summary: cached: -m 6144 fine: --primary-seam-generator=nearest-feature-transform --fine-mask * course: default options. Unreliable, sometimes images are dropped due to seam issues
Thank you for your detailed response! Option --enable-image-cache has been removed long ago for It is still present as a configure option in the debian package for v4.2. I did not check if that is the case for your source package,too. If yes, it should be removed. There is an unmerged branch in the Mercurial repository called mmap_view. I'll have at look at it. From my experience I'd recommend to move to a bigger machine or to reduce the input images' sizes if you are interested in the final image...
Option --enable-image-cache has been removed long ago for it caused image artifacts (i.e. was buggy) in rare circumstances. Moreover, it slowed blending/fusing down considerably and was mutually exclusive with our way of parallelizing execution. If you really want to reactivate such an old version you are completely on your own, though I'd think it is a huge waste of time. There is an unmerged branch in the Mercurial repository called mmap_view. It is a different approach to take pressure off the...
I tried to build with opencl support on windows, but it revealed a few problems with some windows specific issues. The attached patch should help diff --git a/src/fixmath.h b/src/fixmath.h index f10333f..ee29fcd 100644 --- a/src/fixmath.h +++ b/src/fixmath.h @@ -1791,7 +1791,11 @@ public: gsl_function cost = {ciecam_detail::delta_e_min_cost, &extra}; cmsJCh opt_jch = *jch; double delta_e_1d = 0.0; +#ifdef _WIN32 + double delta_e_2d = 0.0; +#else double delta_e_2d __attribute__((unused)) = 0.0; +#endif...
The full build log at pastebin: https://pastebin.com/SFn7N3QM
Hello! First much thanks for enfuse! It is really a nice tool. I've tried to fuse a large focus stack that exceeds my available RAM of 16GB. enfuse gets killed by the kernel once the RAM is full. I found that configure provides an option --enable-image-cache that should allow my task. It is not enabled in my enfuse package from debian repository. I've tried to rebuild the debian package with --enable-image-cache enabled. I've removed --enable-openmp because somewhere I've read these options are exclusive....
Hi Christoph, Thank you for your reply. I've tested with 8 and 16 bit tiff files and the masks contain data that I would expect. Also the resulting blended image is much better. As you said, it seems to be an issue with foating point tiff files. I've also tested with different values for --blend-colorspace, but the ones I tried did not solve the issue. For now I will just convert to 8 or 16 bit tif files and generate the masks with those files. The blend can be done with the floating point images...
Philip - Without your images at hand I can of course only guess where a dragon might be snoring. Floating-point images sometimes show strange effects because of rounding problems in the normalization for non-RGB blending. In modern Enfuse, option --blend-colorspace could correct this. If all of your images are completely masked-out, the effect you mention is expected, too. You could try the following: rescale or crop you input images to say 900x600 pixels and uint8 quantization without alpha-channels....
Maybe also useful information: I'm using Linux (Manjaro), enfuse 4.2 intalled through pacman.
Hi, Just wondering if the following is the expected behaviour. When I create masks from some photos using only exposure weight (--exposure-weight=1) the resulting masks are always black (mask tiff file is only 92kiB). When I increase the width (--exposure-width) the masks becomes gray. When I add or use saturation or contrast weight, the the resulting masks contain valid information (mask tiff is around 60MiB). Am I doing something wrong? I expect the masks also contain valid information when using...
Enblend does not align images; it needs aligned input images. See also Standard Workflow in the Enblend documentation.
Is it possible to use Enblend to align left&right images of a stereopair? Today we are used to do it in StereoPhotomaker, but it lacks command-line invocation option. Thanks, Oleg.
thanks a lot, I like the result so far. It's pretty similar to --hard-mask actually but accentuates movement somewhat more.
A similar attempt: convert IMAGELIST -evaluate-sequence min min.tif convert IMAGELIST -evaluate-sequence max max.tif convert min.tif max.tif -compose difference -composite minmaxdiff.tif If you like to, we can discuss further at https://github.com/mviereck/microscopy-tools/issues .
Thank you so much, I'm trying this right now.
@DerChris ImageMagick might be more what you need. For example, convert IMAGELIST -evaluate-sequence median median.tif will give you a result that makes movements invisible. convert IMAGELIST -evaluate-sequence min min.tif will give you a result that contains all movements. Comparing median.tif with min.tif should give you an idea about the movement. More fine-tuned attempts are possible, though.
Thank you for the reply. I have played around a bit and have found --hard-mask to be pretty effective for what I want. If there are any further suggestions though, I would welcome them and love to test them out.
If I understand your problem Enfuse is the exact opposite of what you need. Enfuse is designed to minimize visual differences or at least trick our vision into believing that there are none. Just take a few frames suitable for combining and run enfuse with different weights (--exposure-weight, --saturation-weight (color images), --contrast-weight, --entropy-weight (b/w images)); set only one to 1 and -- simultaneuously -- all others to 0. That way you'll quickly find out what Enfuse can do. /cls
Hello everyone, I work with videos in scientific research. My goal with Enfuse is to produce a picture of my video that shows all the movements of a person. So if they moved their arm to the left only once in the video, I'd like that reflected visbily in the final picture. In other words, I want Enfuse to care very little about the background which stays the same and more about the changes that happen. In the end, I need the information taken from that enfused picture to select the section of the...
I could not find a bugtracker, so I write here. A gentoo user reported a patch. It fixes enblend so that it can compile with GCC-10. I think it should be merged upstream, if you are fine with the patch. https://bugs.gentoo.org/724988 Please tag a release afterwards. Thank you very much.
Thanksf or the explanation. Would you consider reconsidering hte decision for a new release? It seems that whatever the master branch is now seems to compile OK. Hugins seems to refer version 4.3, which doesn't really exist... It would be good to refer to something for downstream packagers. Thanks again! Mark
Clean up some pedantic warnings.
Drop the test for std::as_const<>
Substitute "ax_cxx_compile_stdcxx_17.m4" for "ax_cxx_compile_stdcxx_11.m4"
CMake: Remove now obsolete tests
CMake: Use now C++17 standard in all builds
Remove our as_const implementation because it is now included in C++17
Remove "optional_transitional.hpp" as it is no longer needed with C++17.
Remove the last remaining dependencies on Boost
Update "filenameparse.cc" module to reflect the C++17 Standard.
CMake: Update search names for lcms2 in newer versions in vcpkg
CMake: Check that exiv2 library is recent enough
CMake: Check also for C++17 <optional> include
MSVC: Fix for new <optional> include
Method allocate::detail::positional_hint::append_location_to() returns address of local temporary.
Add some hints for the transition to C++17 to our README file.
C++17: replace Exiv2::Image::AutoPtr with Exiv2::Image::UniquePtr.
Correct some embarrassing spelling mistakes with codespell(1).
C++17: replace std::as_const<> with std::add_const<>.
Fixes bug in graph-cut algorithm
Fixes memory leak in graphcut algorithm
Unified line breaks
Fixes typo in FindOpenEXR.cmake to correctly find OpenEXR 2.3