multiblend 0.4 released

[Monkey]

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

[Harry van der Wolf]

Hi,

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

Your page mentions multiblend0.4.tar.gz but leads to multiblend0.2.tar.gz. Please correct.
I just put manually the correct version in the address bar and that works.

Harry

[Rogier Wolff]

On Wed, May 09, 2012 at 06:01:16AM -0700, Monkey wrote:

> * removal of some image size limits for 64 bit builds (based on
> changes by Pablo dAngelo)

Oh!!! That sounds promising. I've been working on a large pano the
last few days. It's too big for enblend. I'll let you know how
it goes!

Roger.


--
** R.E....@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.

[Monkey]

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

[Rogier Wolff]

On Wed, May 09, 2012 at 04:02:49PM +0200, Rogier Wolff wrote:
> On Wed, May 09, 2012 at 06:01:16AM -0700, Monkey wrote:
>
> > * removal of some image size limits for 64 bit builds (based on
> > changes by Pablo dAngelo)
>
> Oh!!! That sounds promising. I've been working on a large pano the
> last few days. It's too big for enblend. I'll let you know how
> it goes!

I just started writing that it failed. Somehow, it failed similar to
the older version while loading the first image. I then tested just
blending two images, and that worked. Next I tested blending 6 images,
and that workt too! I noticed in the results that my preparations had
not been good, so now my PC is running nona again....

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

[Rogier Wolff]

On Wed, May 09, 2012 at 06:00:54PM +0200, Rogier Wolff wrote:
> I just started writing that it failed. Somehow, it failed similar to
> the older version while loading the first image. I then tested just
> blending two images, and that worked. Next I tested blending 6 images,
> and that workt too! I noticed in the results that my preparations had
> not been good, so now my PC is running nona again....
>
> I don't know what went wrong: I can't reproduce it.

Good news, bad news.

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?

[Henk Tijdink]

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:

[Monkey]

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

[Bruno Postle]

On Wed 09-May-2012 at 06:01 -0700, David Horman wrote:
>
>I've uploaded a new version of multiblend (0.4), available from
>http://horman.net/multiblend/

Hi David, the version numbers jumping up and down 2 -> 3 -> 31 -> 4
makes this really hard to package for Linux. Anyone with 0.31
installed will have to uninstall it manually before installing 0.4.

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

[Monkey]

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

David

[Bruno Postle]

On Wed 09-May-2012 at 10:30 -0700, David Horman wrote:
>I was going to start going 0.4, 0.4.1 etc from now on - would 0.40 be
>better for this version?

I'm building for fedora assuming that this one is actually 0.40. If
you released 0.4.1, I'd probably pretend that this was 0.40.1.

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