Multiblend 2.0 RC1 - better blending and 300x* faster than Enblend

[Monkey]

(* for a Gigapixel mosaic, anyway; it's complicated, see below)

http://horman.net/multiblend/

It seems Groups won't let me post the quasi-essay I had written, complete with images, so the link above will have to suffice.

Here's Multiblend 2.0, faster, better, more... blendy. I'm calling it a Release Candidate because there's only so much testing I can stand to do, and I've hit a dead-end with features, so I thought I'd put it out there for people to try. I expect some bugs to be found pretty quickly, which I'll hopefully fix pretty quickly.

It's released under GPLv3.

[Terry Duell]

Do you have any build instructions?
I have had a try at building it on Fedora 33, essentially using the rpm spec
file I used ages ago for 0.6.2, with attempts to fix as things went wrong, but
quickly came to a halt with this error, which crops up many times;

/usr/lib/gcc/x86_64-redhat-linux/10/include/pmmintrin.h:56:1: error: inlining
failed in call to 'always_inline' '_mm_hadd_ps(float __vector(4), float
__vector(4))': target specific option mismatch
56 | _mm_hadd_ps (__m128 __X, __m128 __Y)
| ^~~~~~~~~~~

I'm guessing a lot on this as I go.
The build requirements for 0.6.2 were 'libtiff-devel libjpeg-devel libpng-
devel', and I've assumed they will still be required. Are there other
dependencies?

Cheers,
--
Terry Duell <tdu...@iinet.net.au>

[Monkey]

Build "instructions", such as they are - they work for me on WSL Ubuntu, at least - are in the build.txt file:

  g++ -msse4.1 -pthread -ffast-math -Ofast -o multiblend multiblend.cpp -lm -lpng -ltiff -ljpeg

[Harry van der Wolf]

Builds fine and runs fine (under Hugin) on my Ubuntu derived box. GalliumOS 3.1 (Ubuntu 18.04 LTS)

(Linux edgar 4.16.18-galliumos #1 SMP PREEMPT Sun Jun 23 04:14:45 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux)

On MacOS Catalina I had to replace in multiblend.cpp the following:

#include <algorithm>
#include <malloc.h>

#include "tiffio.h"
#include "jpeglib.h"

with:

#include <algorithm>
#ifdef __APPLE__
  #define memalign(a,b) malloc((b))
#else
  #include <malloc.h>
#endif

#include "tiffio.h"
#include "jpeglib.h"

Please correct that before final 2.0 release.

With that it builds fine on MacOS and runs fine under Hugin. I now used Macports instead of homebrew, as I needed macports for pv.

See attached your modified build.txt.

I also created a distributable version: https://mega.nz/file/VEkRlKLY#zt2oymaxcqi1gK-XrKzE0fGiPs8W3lYzXL2yuC89DFM

Unzip the zip with paths (!) to some location of your liking. It will create a folder multiblend-dist and inside you will find multiblend and it's 3rd party necessary libraries.

In Hugin preferences under programs select "use other enblend program" and give the full path to multiblend.

Script to create a distributable multiblend (using macports): https://mega.nz/file/sc8hXIrT#6SYq8Dbei8KZZxocDQ9iSidv__qDJjc7RMaNCwTRFIo

Create a "mac-dist" subfolder in your build directory and use the script from there. Read the info in the script before use.

Of course this script already expects a compiled multiblend in the build folder.

Hoi,

Harry

[Monkey]

Fixed and updated, plus a fix to ignore (properly) an Enblend parameter that was stopping Hugin from successfully calling Multiblend.

http://horman.net/multiblend/

David

[Harry van der Wolf]

And a distributable macos build for multiblend 2.0rc2: https://mega.nz/file/lQtlgKRI#wNYpcmE4-XuZJOsXmxtBkBmB6Ekji-Vp65c38FCaGws

Unzip to a folder of your liking with paths. It should give:

multiblend-dist/
multiblend-dist/Libraries/
multiblend-dist/Libraries/libz.1.2.11.dylib
multiblend-dist/Libraries/libpng16.16.dylib
multiblend-dist/Libraries/libzstd.1.4.8.dylib
multiblend-dist/Libraries/libtiff.5.dylib
multiblend-dist/Libraries/liblzma.5.dylib
multiblend-dist/Libraries/libjpeg.8.2.2.dylib
multiblend-dist/multiblend

Removed a few "sloppy" things from the script:  https://mega.nz/file/FR9CxCpB#ucZGem59Z6n8jVP7NriuqKS9YwGvMtIok9DZqX75vro

Harry

Op za 6 mrt. 2021 om 13:02 schreef Monkey <davidh...@gmail.com>:

--
A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ
---
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hugin-ptx+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/2ea613a7-9e0f-4605-961a-63cf504d461dn%40googlegroups.com.

[Monkey]

Thanks Harry.

[Sergio Amateis]

Hi Monkey

I am only writing to report that my BITDEFENDER TOTAL SECURITY: 

- reports the site   http://horman.net/multiblend/  as dangerous, and blocks it. 

- in the zip with windows binaries, it reports multiblend_x86.exe as a virus, and deletes it. (not a great problem as I think everyone is now on 64bit)

I'm starting to think I'll throw Bitdefender away when my subscription expires.

I will report again after some tests with my big 360 panoramas.

Cheers

Ginosergio

[Monkey]

I uploaded both .exes to VirusTotal. 11/69 reported the x86 version as suspect, and 1/69 reported the x64 version as suspect.

I think this is just a hazard of the ubiquity of viruses. You can probably find something that vaguely resembles some virus in any piece of code. There's nothing particularly clever or unusual in Multiblend's code - no self-modifying code and no built-in compiler, one of which I have previously written and which caused a lot of false positives. It could be something as simple as its use of threads of memory-mapped files that raises suspicions.

As for the site itself, it might be blocked just because it doesn't have HTTPS (my current host is pretty terrible and their Let's Encrypt option doesn't work).

[Sergio Amateis]

Hi Monkey, 

I have done some tests with the same 56 photos 360° Panorama I already sent to you. I have a pto with some masks to avoid bad seams on the buildings.

Stitching this with Multiblend is much much faster but the result is not better than the enblend one. There are stitching errors in the same zones as enblend did, just displaced a little bit. Then I tried to remove all masks and again stitch with enblend and multiblend. This time multiblend shows a few more errors than enblend, but again, results are similar.

Aside from speed, should I find other advantages in multiblend? Is there any parameter I can try, to improve the stiching precision ?

Thank you

Ginosergio

[Monkey]

Sorry, I didn't get around to looking into your project too much. Neither Enblend nor Multiblend can do much about such misalignments, as they come from Hugin's processing of control points, and you have some problematic control points in your project. If you open the Control Point table and sort by distance (highest first) you'll see a lot of control points in sky (click on each one to see them in the Control Point editor) with very high distances, which you should delete - they are either in blue sky, which can't make a good alignment and will drag the rest of the pictures out of alignment, or they are on clouds which move between shots. After deleting those and re-optimising, you should get a better final result - altough you could use more control points on the building, rather than (for example) on the tree behind it (right corner).

David

[Terry Duell]

On Fri, 2021-03-05 at 17:33 -0800, Monkey wrote:
> Build "instructions", such as they are - they work for me on WSL Ubuntu, at
> least - are in the build.txt file:
>
>   g++ -msse4.1 -pthread -ffast-math -Ofast -o multiblend multiblend.cpp -lm -
> lpng -ltiff -ljpeg
>

I should have looked in the archive for instructions, sorry.
It builds OK and I now have an rpm file.
I've not had a chance to test as yet.
Thanks for your help.

[Sergio Amateis]

Hi David, thank you for your help.  I will try another stitch removing the sky's photos and generating a partial panorma.  For the sky, Hugin can't obvioulsy find any control point. So I have entered some points very roughly, just to keep the photos of the sky in the right place. Is there another way to position them better, perhaps manually without using control points?

[bul...@gmail.com]

I do very much appreciate this effort!

Unfortunate the new one fails to stitch a 1.2gigapixel image that the old one stitched perfectly, so I compiled it with -fsanitize=address and got very early this one :

==8137==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x6110000003b0 at pc 0x55be84604975 bp 0x7ffd3aef4e90 sp 0x7ffd3aef4e80
READ of size 1 at 0x6110000003b0 thread T0                                                                                                              
   #0 0x55be84604974 in Threadpool::Wait() (/usr/src/multiblend2/src/multiblend+0x39974)
   #1 0x55be846147ed in Image::Read(void*, bool) (/usr/src/multiblend2/src/multiblend+0x497ed)

[Monkey]

Oh, how embarrassing... for a fix to that immediate problem, change line 96 of threadpool.cpp to read:

        for (i = 0; i < n_threads; ++i) {

-fsantize=address - which I shall try to remember to use in future! - is still reporting some other problems so I'll fix those before I update the source download.

[Monkey]

Errata:

Line 96 of threadpool.cpp should read (as above):

        for (i = 0; i < n_threads; ++i) {

Line 641 of pyramid.cpp should read:

    if (x_shift) memmove(&((float*)line)[1], line, (m128_pitch_hi << 4) - 4);

(the first bit is just for clarity, the 1, now a 4, at the end was a bug)

Line 424 of functions.cpp should read:

    for (i = 0; i < 5; ++i) delete[] real_lines[i];

Line 90 of functions.cpp should read:

        delete[] rows;

This just leaves a bunch of indirect leaks which I should probably clean up one day just to be nice about it but don't have any effect on execution.

[bul...@gmail.com]

Thank you! blending that 1.2gigapix panorama where finally fails at :

13224 x 12248, 10 levels, 16 bpp

Seaming...
Shrinking masks...
Blending...
AddressSanitizer:DEADLYSIGNAL
AddressSanitizer:DEADLYSIGNAL

==17066==ERROR: AddressSanitizer: SEGV on unknown address (pc 0x559fa73dbbee bp 0x7f2334f85b28 sp 0x7f23c27fec60 T1)
==17066==The signal is caused by a READ memory access.                                                                                                  
==17066==Hint: this fault was caused by a dereference of a high value address (see register values below).  Dissassemble the provided pc to learn which
register was used.
   #0 0x559fa73dbbee in Pyramid::CopyPlanarThread_16bit(unsigned short*, int, bool, int, int) (/usr/src/multiblend2/src/multiblend+0x2bbee)
   #1 0x559fa73ee2ce in TP_Thread(void*) (/usr/src/multiblend2/src/multiblend+0x3e2ce)
   #2 0x7f23c66dd6da in start_thread /build/glibc-S9d2JN/glibc-2.27/nptl/pthread_create.c:463
   #3 0x7f23c640671e in __clone (/lib/x86_64-linux-gnu/libc.so.6+0x12171e)

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV (/usr/src/multiblend2/src/multiblend+0x2bbee) in Pyramid::CopyPlanarThread_16bit(unsigned short*, int, bool, int, int)
Thread T1 created by T0 here:
   #0 0x7f23c777e7c1 in pthread_create (/usr/lib/x86_64-linux-gnu/libasan.so.6+0x567c1)
   #1 0x559fa73ed67a in Threadpool::Threadpool(int) (/usr/src/multiblend2/src/multiblend+0x3d67a)

==17066==ABORTING

[bul...@gmail.com]

Don't think this one is a mere OOM problem since it happens even with --cache-threshold=1G 

[bul...@gmail.com]

FWIW, converting the source tiffs to 8bit works. Although with leaks in ShrinkMasks.

[Monkey]

Ugh, that had me stumped for a while. I couldn't work out why it was telling me it was trying access 0x0000000000000000.

Anyway, the solution is to change lines 316 and 325 of pyramid.cpp to:

                pixels = _mm_loadu_si128(src_pp_m++);

[bul...@gmail.com]

Works. No more crash.

[bul...@gmail.com]

Question: Any possibility to convert some of the mallocs to MapAlloc? Could this prevent some OOM cases I encountered when blending very large scans (1.2g+0.8g 8-bit tiffs)?

[Monkey]

You can probably replace any malloc except the one on line 20 of functions.cpp, but they should all be pretty small anyway. I'm guessing it's the seam map that's growing too large, but if you set --cache-threshold=1 that should cache all the images before it gets to the seam map and might give you enough RAM to finish.

I'll try to implement cacheable, reallocable Flex class data in a future version.

[bul...@gmail.com]

--cache-threshold=1 did not help, but MAP_SHARED | MAP_NORESERVE did.

[bul...@gmail.com]

Still, it seems to be quite more memory hungry than the old version.

[Alan Cossitt]

I'll give it a shot. last time I used it it for a aerial 360 it removed cars and other ground objects.

[Monkey]

Has anyone out there tried either the x64 or x86 versions of Multiblend 2.0 on Windows XP or Windows Vista? Someone's reporting vcredist problems and I'm not sure if it's because I built using the latest platform toolset.

[Florian Königstein]

Monkey, I much appreciate your software.

I like it because I like big panoramas ... and the speedup is welcome.

For big panoramas there's another issue: Geometrical optimization is slow.

I developed a fork for the libpano library that I called fastPTOptimizer.

For large panoramas the speedup factor for optimization can be 100 or more.

I integrated both your multiblend and my fastPTOptimizer into a "development version" of Hugin.

Multiblend is now the default enblend-like program (in the GUI is still written "enblend"

but you can see that multiblend is used by choosing Preferences / Programs).

Only the CMakeLists.txt files are not updated so that Multiblend is automatically integrated

because I'm not yet so familiar with creating files for CMake.

My version of Hugin is here:

https://sourceforge.net/projects/huginplusplus/files/development/

[Florian Königstein]

Sorry, there is some bug in the windows installer. Currently optimization doesn't work at all for large panoramas. I will work on this.

[Florian Königstein]

Now the bug should be fixed in the Windows installer. There was a problem with an incompatible link library.

Due to a mail from T. Modes I reverted making Multiblend the standard blender, so enblend is again standard.

But the installer copies multiblend.exe into the folder

C:\Program Files\Hugin++\bin

so the user can activate multiblend with the menu "Preferences / Programs / Use alternative enblend application"

The reason is that in the current version Multiblend doesn't support HDR images, so stitching HDR would not be possible

in the default settings if Multiblend was the standard blender.

[Klaus Foehl]

Hello,

as there is actual coding of new software going on, maybe one can iron out a deficiency in the Hugin lens model. At least lay the groundwork for it.

The Brown-Conrady model parameters are sound, but the intersection with the abc-Hugin parameter set contains only one (1) non-trivial distortion parameter.

I suggest to add further Brown-Conrady parameters to the software code you are currently writing. Now.

Best regards

Klaus

--

A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ
---
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hugin-ptx+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/2699006b-895d-42f4-bd19-6ed0d3f3863bn%40googlegroups.com.

[Florian Königstein]

I tried to stitch a panorama with 1350 images with multiblend. It didn't work in Windows because the command line where all the image filenames are listed was longer than 32768 characters. At least in Windows the limit is 32768 (or maybe one less).

I suggest adding the possibility to read the command line arguments from a file.

I changed multiblend.cpp so that you can add a command line option  --argfile filename  or  --argfile=filename . After this no further arguments may follow in the command line, but each line in the file "filename" counts as another argument, e.g. call

multiblend.exe" --argfile=test.txt

with test.txt containing e.g.

--compression=LZW

-o

test110.tif

--

test1100000.tif

test1100001.tif

...

In the attachment I have the modified version of multiblend.cpp.

Maybe Hugin and HuginExecutor could be changed so that the arguments are written in a file if they are many.

Florian

[Gunter Königsmann]

AFAIK if you pass the parameter @filename to a program on ms windows the contents of the file "filename" is used as command-line parameters. Thw last time I tried if the parameters are read from a file the maximum length was higher than the 256 bytes the limit was at back then.

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.

[Monkey]

Thanks Florian, that's a great suggestion and I'll incorporate into the source distribution at some point. Out of interest, how long did the blend take? Was the final pixel count?

[Florian Königstein]

For me it does not work if I use  multiblend.exe @test.txt  instead of  multiblend.exe --argfile=test.txt on Windows.

AFAIK on Linux you can do this with some other syntax (I'm not so familiar with Linux). But building something like an --argfile option into Multiblend has the other advantage that is works OS independent.

I have stitched nearly 1 GPixels with Multiblend in about 6 minutes. It's super fast. Thanks @ Monkey !

The maximum memory usage was about 24 GBytes. My photos would allow to stitch it to about 10 GPixels, but due to my RAM (64 GBytes) I will probably only be able to stitch about 2 - 2.5 GPixels.

[Monkey]

Don't forget that the 64-bit version of Multiblend will use disk space (system temp or specified directory) if there isn't enough RAM.

[Florian Königstein]

I tested it so that more memory than I have RAM is used.

But Multiblend crashed when stitching 1351 photos to an output size of 88291 x 61567 Pixels.

I started it again with the Visual Studio 2019 Debugger.

The input options were Multiblend --argfile=test.txt with test.txt containing

--bigtiff

--all-threads

-f88291x61567+18125+0

--compression=LZW

-o

test119.tif

test1190000.tif

test1190001.tif

test1190002.tif

...

test1191350.tif

The console output was

ignoring Enblend option -f

Multiblend v2.0.0 (c) 2021 David Horman        http://horman.net/multiblend/

----------------------------------------------------------------------------

Processing test1190000.tif...

Processing test1190001.tif...

Processing test1190002.tif...

...

Processing test1191350.tif...

88291 x 61567, 11 levels, 8 bpp

Seaming...

Warning: test1190001.tif is fully obscured by other images

Warning: test1190002.tif is fully obscured by other images

   .... some other images obscured ....

Warning: test1191350.tif is fully obscured by other images

Shrinking masks...

Blending...

The crash was in the function CompositeLine() in the following line:

       if (i == 0) memset(&output_p[x], 0, mask_count << 2);

The pointer output_p is 0x0000026321b85980, "Unable to read memory". mask_count is 88291.

In the calling function main() and the lambda function the variables were:

   i = 0

   l = 0

- in_level {width=12324 height=5502 pitch=12328 ...} Pyramid::Level

width 12324 int

height 5502 int

pitch 12328 int

m128_pitch 3082 int

bytes 271413248 unsigned __int64

+ data 0x0000025ed3e23080 {0.00000000} float *

x 75967 int

y 0 int

x_shift true bool

y_shift false bool

upper_x_shift false bool

upper_m128_pitch 0 int

- bands { size=3 } std::vector<int,std::allocator<int>>

[capacity] 3 __int64

+ [allocator] allocator std::_Compressed_pair<std::allocator<int>,std::_Vector_val<std::_Simple_types<int>>,1>

[0] 0 int

[1] 2748 int

[2] 5502 int

+ [Raw View] {_Mypair=allocator } std::vector<int,std::allocator<int>>

- out_level {width=88291 height=61567 pitch=88296 ...} Pyramid::Level

width 88291 int

height 61567 int

pitch 88296 int

m128_pitch 22074 int

bytes 4564963328 unsigned __int64

+ data 0x0000026099c20000 {0.00000000} float *

x 0 int

y 0 int

x_shift false bool

y_shift false bool

upper_x_shift false bool

upper_m128_pitch 0 int

- bands { size=3 } std::vector<int,std::allocator<int>>

[capacity] 3 __int64

+ [allocator] allocator std::_Compressed_pair<std::allocator<int>,std::_Vector_val<std::_Simple_types<int>>,1>

[0] 0 int

[1] 30780 int

[2] 61567 int

+ [Raw View] {_Mypair=allocator } std::vector<int,std::allocator<int>>

x_offset = 75967

y_offset = 0

sy = 30780

ey = 61567

y = 30780

The input files have a total size of 90 GBytes, but if nothing helps, I could upload them somewhere.

On Thursday I stitched the same project, but it was scaled with nona so that the output became 36534 x 25476 Pixels. Multiblend used only the RAM (about 24 GBytes). It ran without problems.

Maybe you can provocate this error when simulating less RAM e.g. with a virtual machine and using less images.

[Monkey]

Ah, how foolish of me, I think I failed to account for the required number of bytes overflowing a 32-bit value.

Does it work if you change line 31 of pyramid.cpp from

        size_t bytes = pitch * ((height + y_shift + 3) & ~3) * sizeof(float);

to

        size_t bytes = (size_t)pitch * ((height + y_shift + 3) & ~3) * sizeof(float);

?

[Florian Königstein]

I changed it and ran it in a Release build because running the Debug version takes much more time. The release version stopped with the following console output:

Warning: test1191347.tif is fully obscured by other images

Warning: test1191349.tif is fully obscured by other images

Warning: test1191350.tif is fully obscured by other images

Shrinking masks...

Blending...

So, no meesage "writing .. output file". And test119.tif (the output file) contains 0 bytes. Probably the Debugger would raise an error at the same line. At night I will run the new version with the debugger.

[Monkey]

Line 683 of image.cpp - please replace

    size_t channel_bytes = (width * height) << (bpp >> 4);

with

    size_t channel_bytes = ((size_t)width * height) << (bpp >> 4);

I would test this myself but my one attempt caused my computer to freeze and need a hard reset, which I hate doing!

[Monkey]

Actually never mind, that probably isn't it... I'll keep looking.

[Florian Königstein]

With the Debugger I see that it now crashed in the function   template <typename F> void Pyramid::OutPlanar8 _OP_  in the line

          _mm_storeu_si128(dst_pp_m++, pixels);

dst_pp_m points to an unreadable position. However *dst_p is readable (above dst_pp_m = (__m128i*)dst_p; was executed).

[Monkey]

The most probable culprit is line 167 in pyramid.h which should be changed to:

    dst_p += (size_t)(sy - (level ? 1 : 0)) * pitch;

Line 169 should also be changed to:

    p_pt += (size_t)m128_pitch * sy;

although it is probably not the cause of the problem in this case.

[Florian Königstein]

Very fine, it works now. Thank you for fixing.

For this panorama Multiblend took about 40 minutes. The final tiff file has about 14 GBytes. Windows could not open it (probably too large), but with GIMP I could view it.

[Florian Königstein]

Now I know what Gunter meant with passing @filename to a program. This is not a feature

of the Windows OS, but enblend and enfuse support it.

So I changed my modification of multiblend so that you can (and must) use @filename instead of

-argfile=filename of -argfile filename.

Enblend and enfuse seem to support also nested "response files" and wildcards in the filenames. And

the lines in a @filename - file seem to be all interpreted as images - not as other parameters.

In my modification of multiblend they are interpreted as further arguments - these can be images if placed

after the -o outputfile.

I also changed my fork of Hugin (Hugin++) so that a temporary file with the image filenames is created if

the command line would be longer than about 7000 characters (8191 - 1024, older versions of

Windows support only 8191 chars in a command line, and for other arguments I reserved generously 1024 chars).

So Hugin++ works both with enblend and with my modified Multiblend if the command line would be too long.

[ChameleonScales]

Hi everyone,

I'd like to give multiblend 2.0 rc3 a try but the given build command for Linux gives this error :

multiblend.cpp:31:10: fatal error: tiffio.h: No such file or directory

and indeed there is no such file.

What now ?

[Gunter Königsmann]

That means a library is missing. What kind of Linux system do you use?

[ChameleonScales]

I'm on Debian. I don't have any package called tiffio in my repos.

[Kornel Benko]

Am Sun, 08 Aug 2021 00:01:58 +0000
schrieb "'ChameleonScales' via hugin and other free panoramic software"
<hugi...@googlegroups.com>:

On debian it is part of 'libtiff5-dev' package.

Kornel

[ChameleonScales]

Thank you!
I then got a similar error related to png but I just had to install libpng-dev and it could build without any error.

[Pierre Carreaud]

@Florian K¨nigstein, @Monkey, do you plane to release a RC5 with the fixes you identified ? (limited number of images because of windows args in console, and silent crashes of Multiblend?)

I almost have the same problems with big panoramas while charging tiff files or blending: Multiblend stops with no errors.

I also found that multiblend reads the geotiff tag, but in order to make it work, I have to modify the georeference informations with Y=-Y.

I'm trying to give you the exact lines of code to change.

This tool is a game changer in th image assembly solutions!

Best regards,

[Monkey]

I finally got around to packaging up the files with the last few bugfixes. It doesn't include list file processing though, which is still on the to-do list.

https://horman.net/multiblend/

[Florian Königstein]

Thank you for the update. I took it, but kept my changes in the file multiblend.cpp so that I can use the syntax @file for reading the image file names from a file.

I took a large panorama project with 1351 images and 273471 control points and preprocessed the images with nona.exe . Nona procuced at least one image that has no content, but only transparency (the size is 250 x 152 pixels, GIMP says 10333 x 2583).

Multiblend crashes when reading this image in the function   void Image::Read()   in the file image.cpp . When running it with the debugger, I see the following exception:

Run-Time Check Failure #3 - The variable 'right' is being used without being initialized (line 331 in file image.cpp  :   if (right < left) std::swap(left, right); ).

Probably in the preceding for-loops the if-interrogation never evaluate to true so that 'right' is uninitialized.

I attach the file with that the error occurs.

[Florian Königstein]

I fixed the bug myself. Therefor I changed the files image.cpp and multiblend.cpp. I have these files in the attachment. But the file multiblend.cpp contains additionally my prior changes that enable the syntax @file for reading the image filenames from a file.

Furthermore, I fixed a memory leak bug in the file multiblend.cpp (the objects of class Image that are created via new Image(...) were not freed with delete at the end of main()).

[Tobias]

Hello,

what about creating an github or gitlab repository for multiplend? This would make the patch handling easier.

Regards,

Tobias

Monkey schrieb am Sonntag, 12. Dezember 2021 um 15:57:15 UTC+1: