Hi all,

I've uploaded a new version of multiblend (0.4), available from
http://horman.net/multiblend/

New features:

* --save-seams and --load-seams for external editing of seams
* TIFF position offsets are now preserved
* removal of some image size limits for 64 bit builds (based on changes by
Pablo dAngelo)
* (untested) GeoTIFF support (based on changes by Pablo dAngelo)

--save-seams saves a paletted 8-bit PNG which can be edited and used in a
second run with --load-seams - just remember to turn any anti-aliasing or
resampling off ;)

As a result of these changes multiblend now has a dependency on libpng.

The code's also been tidied up a little, a few functions more sensibly
renamed, etc - sorry if this breaks anyone's patches!

There's also a new hidden switch, --save-masks, which saves out the mask
pyramids as PNGs. It's not of any real use, but some have reported blending
problems when compiling with gcc 4.7.0, and this may help get to the bottom
of it.

As usual, please report any problems either here or by email - thanks!

David

Hi,

2012/5/9 Monkey <davidhorma...@gmail.com>

Harry

        Roger.

--
** R.E.Wo...@BitWizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 **
**    Delftechpark 26 2628 XH  Delft, The Netherlands. KVK: 27239233    **
*-- BitWizard writes Linux device drivers for any device you may have! --*
The plan was simple, like my brother-in-law Phil. But unlike
Phil, this plan just might work.

Don't get too excited, it has still has many limitations with regard to
image size which I will slowly get around to addressing :)

Harry, thanks for pointing out my mistake - it's now fixed :*)

David

I don't know what went wrong: I can't reproduce it.

        Roger.

--
** R.E.Wo...@BitWizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 **
**    Delftechpark 26 2628 XH  Delft, The Netherlands. KVK: 27239233    **
*-- BitWizard writes Linux device drivers for any device you may have! --*
The plan was simple, like my brother-in-law Phil. But unlike
Phil, this plan just might work.

The bad news: It crashes again. The good news: I know what triggers
it.

It's the images that wrap around the 0/360 degree mark that cause the
troubles.

David, would the algorithm in multiblend lend itself to a "priority"
scheme?

In my current panorama that I'm stitching, I have take 15 portrait
shots for the 360 degree "background" at 18mm focal length.  Clouds,
some houses closeby etc etc. But then I shot the interesting parts at
135mm focal length. About 23 more images.

So now I have 38 images. Most of the 1.2G pixels are interpolated from
the "low-res" 18mm shots. However, when we get to the tele-lens photos
we get interesting parts that should "override" the lowres images.
Currently I manually cut out a mask for the parts that I know I've shot
in highres.

Apparently I'm not good at this because I still get:

WARNING: some images completely overlapped
WARNING: some image areas have been arbitrarily assigned

So my question: could some priority be given to the "highres" images?

Anyway, after loading all images that do not overlap the 0/360
boundary I still get:

And then after "blending..." I still get:

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff710ac50 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
(gdb) where
#0  0x00007ffff710ac50 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x0000000000409a81 in mask_into_output (input=0x63d440, mask=0x5c80410, output=<optimized out>, first=<optimized out>) at /usr/include/x86_64-linux-gnu/bits/string3.h:85
#2  0x000000000040a73d in blend () at blending.cpp:766
#3  0x000000000040c195 in go (argv=<optimized out>, input_args=<optimized out>) at go.cpp:74
#4  0x0000000000401c87 in main (argc=38, argv=0x7fffffffe038) at multiblend.cpp:184
(gdb)

whereas when I give it an image that overlaps 0/360 I get it while
loading that image:

loading p78370000.tif...

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff7b9fe16 in ?? () from /usr/lib/x86_64-linux-gnu/libtiff.so.4
(gdb) where
#0  0x00007ffff7b9fe16 in ?? () from /usr/lib/x86_64-linux-gnu/libtiff.so.4
#1  0x00007ffff7bae3e9 in TIFFReadEncodedStrip () from /usr/lib/x86_64-linux-gnu/libtiff.so.4
#2  0x0000000000404e3f in load_image (image=0x610960) at loadimages.cpp:964
#3  0x0000000000405237 in load_images (argv=0x7fffffffe340, argc=1) at loadimages.cpp:1029
#4  0x000000000040be80 in go (argv=0x7fffffffe340, input_args=1) at go.cpp:18
#5  0x0000000000401c87 in main (argc=4, argv=0x7fffffffe328) at multiblend.cpp:184
(gdb)

This is not due to "out of memory" or something like that. Strace
shows:

mmap(NULL, 363035874, PROT_READ, MAP_SHARED, 4, 0) = 0x7f54fbb1d000
mmap(NULL, 602636288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f54d7c65000
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
+++ killed by SIGSEGV +++
Segmentation fault

It mmaps the 300M input file (fd=4), then mallocs (using mmap again),
600Mb of image data. and then crashes.

Hmm..... Could it be that it's calculating the "memory to alloc" in an
int and then allocing 600M instead of 4G+600M?

        Roger.

--
** R.E.Wo...@BitWizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 **
**    Delftechpark 26 2628 XH  Delft, The Netherlands. KVK: 27239233    **
*-- BitWizard writes Linux device drivers for any device you may have! --*
The plan was simple, like my brother-in-law Phil. But unlike
Phil, this plan just might work.

Hello David

I tried to download the zipversion for windows, but I got the error message
it can't be found on the server.
The tar.gz version I can download.

Kind regards,
Henk

Op woensdag 9 mei 2012 15:01:16 UTC+2 schreef Monkey het volgende:

Oh dear, it's really not my day... the Windows binary download is now
fixed, sorry Henk!

There is a kind of image priority, in that those "arbitrarily assigned"
areas will be filled with the first image that can be used (based on
command line order). This can be reversed with --reverse, or just altered
as you wish by altering the order of the input images on the command line
(i.e. put the telephoto images first).

As for the other crashes, I'm really not sure. There could still be some
unchecked mallocs in there - I am a very lazy programmer - but I had
thought I had updated everything to use size_t when calculating memory
requirements, instead of int. Perhaps line 961 in loadimages.cpp is a
problem, where it's calculated inline by multiplying/shifting ints? What
are the dimensions/bpp of the problem image?

One future update I have in mind is better handling of wrapped images by
splitting them in two (where possible) since most of it may be the empty
space in the middle.

Davd

I know this seems like a minor point, but seamless upgrades are
one of the things that takes the grief out of using software.

--
Bruno

I was going to start going 0.4, 0.4.1 etc from now on - would 0.40 be
better for this version?

David

There are few people using a packaged multiblend at this point, so
really you can use whichever system you prefer for the future.

Hugin has three numbers (2011.4.0), but in practice we only use two
of them.  The last number is in case we really have to push out a
bugfix for a stable version and this hasn't been necessary so far.

--
Bruno