multiblend - a faster alternative to Enblend (Windows only)

[Monkey]

Hi all,

I've developed an alternative to Enblend which I hope might find some
interested users here. It's not a better blender, and it lacks many of
Enblend's features, but it has two redeeming qualities - the first is
a 64-bit version, which means it can use more memory, and the second
is that it is much faster. In testing on a 560 megapixel 7x7 mosaic,
it was 172x faster than Enblend (at least; Enblend ran out of memory
before it could finish).

It should work straight out of the box as Hugin's "alternative Enblend
program". There is some more information about how it works and its
(very few) options at http://horman.net/multiblend/

Download: http://horman.net/multiblend/multiblend0.1.zip (Windows
only)

I'd appreciate any feedback, especially bug reports.

David

[Jan Martin]

Looks interesting.
Any chance for a Linux version?

--
You received this message because you are subscribed to the Google Groups "Hugin and other free panoramic software" group.
A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ
To post to this group, send email to hugi...@googlegroups.com
To unsubscribe from this group, send email to hugin-ptx+...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx

[Monkey]

Hi Jan,

I don't have much experience compiling C under Linux (this version was
built with Visual C++ Express) but I don't think there is too much
Windows-specific stuff in there (it does #include <windows.h> but I
can't remember why!). All the file management is done with libtiff so
that should be okay, but there is some SSE stuff that might need
translating. I'll see about tidying up the source and letting it
loose.

David

[Carlos Eduardo G. Carvalho (Cartola)]

I am also interested in a Linux version and would probably try it on FreeBSD. I will download the windows version to try it.

Thanks!

Carlos E G Carvalho (Cartola)
http://cartola.org/360

2011/12/29 Monkey <davidh...@gmail.com>

[Ian Tindale]

I’d be interested in one that can run on Lion / OS X 10.7

--
Ian Tindale

[Bart van Andel]

Sounds interesting and I'd like to try it, but unfortunately my virus scanner popped up a warning while attempting to download the file. Has the file been tempered with?

Warning In order not to compromise your security, this page will not be accessed

A virus or unwanted program was found in the HTTP data of the requested page.

Requested URL:		http://horman.net/multiblend/multiblend0.1.zip
Information:		Is the TR/Crypt.XPACK.Gen Trojan

Generated by Web Protection 12.01.06.17, AVE 8.2.8.14, VDF 7.11.20.66

[Monkey]

Hi Bart,

The executables have been compressed with Mpress (http://
www.matcode.com/mpress.htm) - I'll put uncompressed versions up in
about an hour or so.

I don't have any access to a Mac, unfortunately. If I can get the
source compiling on Linux, would that mean it should be easy to
compile on a Mac? libtiff is multiblend's only real dependancy.

David

On Dec 29, 2:29 pm, Bart van Andel <bavanan...@gmail.com> wrote:
> Sounds interesting and I'd like to try it, but unfortunately my virus
> scanner popped up a warning while attempting to download the file. Has the
> file been tempered with?
>
> [image: Avira]

>  Warning
> In order not to compromise your security, this page will not be accessed
> A virus or unwanted program was found in the HTTP data of the requested
> page.
>

> *Requested URL:*http://horman.net/multiblend/multiblend0.1.zip*Information:*Is

[Monkey]

Non-compressed executables:

http://horman.net/multiblend/multiblend0.1uncomp.zip

[Carlos Eduardo G. Carvalho (Cartola)]

If it compiles in Linux and FreeBSD I would guess that if some new chance is necessary to compile in a Mac would be small.

Carlos E G Carvalho (Cartola)
http://cartola.org/360

2011/12/29 Monkey <davidh...@gmail.com>

Hi Bart,

[Monkey]

A very minor update:

http://horman.net/multiblend/multiblend0.1a.zip

This adds a "--bgr" switch, as one user has reported the red and blue
channels being swapped on output - I'm not sure what has caused the
problem yet.

David

[Harry van der Wolf]

Hi David,

2011/12/29 Monkey <davidh...@gmail.com>

As soon as you have a source code version available I will try to compile it on MacOSX.
I'm very happy with enblend but I really like to try multiblend.

Harry

[Stefan de Konink]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Is there sourcecode somewhere so porting (except for using Wine) would
be easier ;)

Stefan
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEAREKAAYFAk782owACgkQYH1+F2Rqwn30XwCgknZNMlrDD9V0k19N6T128Ffk
Q/gAnR2kAV0FhkVAOrizKo0ECxixLBh/
=D2lJ
-----END PGP SIGNATURE-----

[Monkey]

Good news, everyone!

I've made changes to the source code so my Visual C++ solution still
builds, but it now also builds on Linux with g++. I still want to tidy
up the source code a little more before I release it (real programmers
will probably still be shocked at the state of it ;) ), but hey, at
least it works!

I'll make something available this weekend.

David

[Frederic Da Vitoria]

2011/12/30, Monkey <davidh...@gmail.com>:

Please don't forget the non-MPressed versions. Anyhow, I read
somewhere that compressing executables in Windows was not entirely a
good idea (see http://en.wikipedia.org/wiki/Executable_compression )

--
Frederic Da Vitoria
(davitof)

Membre de l'April - « promouvoir et défendre le logiciel libre » -
http://www.april.org

[Monkey]

> Please don't forget the non-MPressed versions.

You're right - I won't bother MPressing them in future. I just wanted
to get the size in under 100k ;)

The Linux executable builds to about 54k, but I think that's because
libtiff is dynamically linked in this case. It's giving me segfaults
today, so I will need to fix that before I upload the source.

David

[Monkey]

http://horman.net/multiblend/multiblend0.1a.tar.gz

I've included my build command, which was just

g++ -ltiff -msse2 -O2 multiblend.cpp

though I have libtiff-devel installed from an RPM, so I'm not sure
what hoops others may have to jump through to get it working.

Trying to compile it with -O3 was causing the segfaults yesterday.

David

[Harry van der Wolf]

Hi,

2011/12/31 Monkey <davidh...@gmail.com>

On Ubuntu 11.10 I have libtiff4-dev, libtiff4 and libtiffxx0c2 installed, but I get the following errors:

g++ -ltiff -msse2 -O2 multiblend.cpp

/tmp/ccNNU5W4.o: In function `load_image(struct_image*)':
multiblend.cpp:(.text+0x1aa5): undefined reference to `TIFFOpen'
multiblend.cpp:(.text+0x1ac7): undefined reference to `TIFFGetField'
multiblend.cpp:(.text+0x1aeb): undefined reference to `TIFFGetField'
multiblend.cpp:(.text+0x1b12): undefined reference to `TIFFGetField'
multiblend.cpp:(.text+0x1b3c): undefined reference to `TIFFGetField'
multiblend.cpp:(.text+0x1b63): undefined reference to `TIFFGetField'
/tmp/ccNNU5W4.o:multiblend.cpp:(.text+0x1b7b): more undefined references to `TIFFGetField' follow
/tmp/ccNNU5W4.o: In function `load_image(struct_image*)':
multiblend.cpp:(.text+0x1c68): undefined reference to `TIFFNumberOfStrips'
multiblend.cpp:(.text+0x1c9f): undefined reference to `TIFFNumberOfStrips'
multiblend.cpp:(.text+0x1cda): undefined reference to `_TIFFmalloc'
multiblend.cpp:(.text+0x1d17): undefined reference to `TIFFReadEncodedStrip'
multiblend.cpp:(.text+0x1d1f): undefined reference to `TIFFStripSize'
multiblend.cpp:(.text+0x1ded): undefined reference to `_TIFFfree'
multiblend.cpp:(.text+0x1e3d): undefined reference to `TIFFClose'
multiblend.cpp:(.text+0x1f3d): undefined reference to `TIFFNumberOfStrips'
multiblend.cpp:(.text+0x1f50): undefined reference to `TIFFRawStripSize'
multiblend.cpp:(.text+0x1f74): undefined reference to `TIFFRawStripSize'
multiblend.cpp:(.text+0x1f9f): undefined reference to `TIFFNumberOfStrips'
multiblend.cpp:(.text+0x1fb2): undefined reference to `TIFFRawStripSize'
/tmp/ccNNU5W4.o: In function `tiff_out()':
multiblend.cpp:(.text+0x5ea4): undefined reference to `TIFFSetField'
multiblend.cpp:(.text+0x5ec2): undefined reference to `TIFFSetField'
multiblend.cpp:(.text+0x5ee0): undefined reference to `TIFFSetField'
multiblend.cpp:(.text+0x5efd): undefined reference to `TIFFSetField'
multiblend.cpp:(.text+0x5f1a): undefined reference to `TIFFSetField'
/tmp/ccNNU5W4.o:multiblend.cpp:(.text+0x5f38): more undefined references to `TIFFSetField' follow
/tmp/ccNNU5W4.o: In function `tiff_out()':
multiblend.cpp:(.text+0x62c2): undefined reference to `TIFFWriteEncodedStrip'
multiblend.cpp:(.text+0x62e2): undefined reference to `TIFFClose'
multiblend.cpp:(.text+0x6537): undefined reference to `TIFFSetField'
multiblend.cpp:(.text+0x6563): undefined reference to `TIFFSetField'
/tmp/ccNNU5W4.o: In function `go(char**, int)':
multiblend.cpp:(.text+0x6587): undefined reference to `TIFFSetWarningHandler'
multiblend.cpp:(.text+0x65a9): undefined reference to `TIFFOpen'
multiblend.cpp:(.text+0x6669): undefined reference to `TIFFOpen'
collect2: ld gaf exit-status 1 terug

On MacOSX I also have libtiff including it's include files installed. I set the necessary paths to includes and libs by hand, after the first erroneous runs, but I get the errors like in the attached OSXoutput.txt (too long to include in this mail. notepad can't read unix style text files correctly. Use worpad or any other more advanced editor than notepad).

I know that (almost) all errors have to do with the tiff include, but even when specifying the path to the tiff include it doesn't work. I also changed "tiffio.h" to <tiffio.h> and back but that doesn't seem to make a difference either. I also specified the environment settings TIFFINC and LIBTIFF: no difference either. Only when I specify the full path to the tiffio.h like "<path_to>/tiffio.h> it is found.

On OSX I also had the error with malloc not being found, so I made a small patch. See attached. Note that your code is made on Windows while I'm on Mac OS X (by default) and every now and then on (L)Ubuntu. That causes the ^M line endings.

Harry

[Kornel Benko]

Am Samstag, 31. Dezember 2011 um 14:20:05, schrieb Harry van der Wolf <hvd...@gmail.com>

> Hi,
>
> 2011/12/31 Monkey <davidh...@gmail.com>
>
>
> > http://horman.net/multiblend/multiblend0.1a.tar.gz
> >
> > I've included my build command, which was just
> >
> > g++ -ltiff -msse2 -O2 multiblend.cpp
> >
> > though I have libtiff-devel installed from an RPM, so I'm not sure
> > what hoops others may have to jump through to get it working.
> >
> > Trying to compile it with -O3 was causing the segfaults yesterday.
> >
> > David
> >
> >
> On Ubuntu 11.10 I have libtiff4-dev, libtiff4 and libtiffxx0c2 installed,
> but I get the following errors:
>
> g++ -ltiff -msse2 -O2 multiblend.cpp

I have no error if using
g++ -msse2 -O2 multiblend.cpp -ltiff -ltiffxx

on ubuntu 11.10

Kornel

[Harry van der Wolf]

2011/12/31 Kornel Benko <Kornel...@berlin.de>

I have no error if using
       g++  -msse2 -O2 multiblend.cpp -ltiff -ltiffxx

on ubuntu 11.10

       Kornel

Thank you. You hit a blind spot. It now works on my Lubuntu 11.10 as well.

Unfortunately it doesn't change a thing on OSX.

Hary

[Harry van der Wolf]

2011/12/31 Harry van der Wolf <hvd...@gmail.com>

Harry

On OSX it now compiles with:

g++ -L/opt/local/lib -I/opt/local/include -msse2 -O2 multiblend.cpp -ltiff -o multiblend

Harry

[Monkey]

Harry, thanks for the OSX patch - I've added it to the source and
updated the tar.gz (http://horman.net/multiblend/
multiblend0.1a.tar.gz)

Just to be clear though, it compiles and works okay on OSX if you
specify the full path to tiffio.h (and include your malloc patch)?

Sorry for the problems - not having OSX to play with, and not really
being used to distributing my creations, I'm afraid I'm stumbling in
the dark on this one!

David

[Harry van der Wolf]

2011/12/31 Monkey <davidh...@gmail.com>

David

-

Our mails just crossed. I don't need to specify the full path to tiffio.h anymore. I just use the line:

g++ -L/opt/local/lib -I/opt/local/include -msse2 -O2 multiblend.cpp -ltiff -o multiblend

Note that this is for a Macports dev environment on OSX. If someone uses the Fink dev environment I think it should be:
g++ -L/sw/lib -I/sw/include -msse2 -O2 multiblend.cpp -ltiff -o multiblend
(but that's untested as I don't have Fink)

I have now also compiled multiblend for i386 and x86_64 for OSX. I don't think ppc will succeed as sse2 is not supported on ppc.

I will do some testing now on OSX.

Hary

[Rogier Wolff]

On Sat, Dec 31, 2011 at 03:42:35PM +0100, Harry van der Wolf wrote:
> I have now also compiled multiblend for i386 and x86_64 for OSX. I don't
> think ppc will succeed as sse2 is not supported on ppc.

The code just uses some optimizations that can easily be written out
for other processors.

For example:

__m128i _mm_add_epi16 (__m128i a, __m128i b);

would be something like:

typedef short[8] __m128i;

__m128i add_epi16 (__m128i a, __m128i b)
{
int i;
__m128i t;

for (i=0;i<8;i++)
t[i] = a[i] + b[i];
return t;
}

The question is: does the compiler support passing 128bit variables
around like that.

The thing is that sse speeds this kind of operation up a lot. :-)

Hopefully a library that provides these compatibility functions
already exists.

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.

[Harry van der Wolf]

Hi David,

2011/12/31 Monkey <davidh...@gmail.com>

Harry, thanks for the OSX patch - I've added it to the source and
updated the tar.gz (http://horman.net/multiblend/
multiblend0.1a.tar.gz)

David

I'm very sorry but I sent you the first patch instead of the second. The memalign function is non existent on OSX. So after having created the first patch I discovered that OSX doesn't need malloc.h but only one definition.
It's in this second patch.

Harry

[Harry van der Wolf]

Hi David,

Maybe not yet clear to you, but my results/remarks/questions/b.llsh.t is always related to Mac OS X.
I built multiblend now also universal, but only for intel. When building universal for multiple architectures I can't use -O2 optimization either as it segfaults as well. It's now at -O.

multiblend is indeed much, much faster then enblend. From the 3 comparing tests the resulting images were "equal" to me w.r.t. seams and so on.

Thanks for this addition.

Two question though:
- Is multiblend GPL (V2/V3)?
- Does multiblend contain patent/license bound code?

Harry

[Monkey]

Hi Harry,

Thanks for the update on the patch - I've made the change and
reuploaded.

> multiblend is indeed much, much faster then enblend. From the 3 comparing
> tests the resulting images were "equal" to me w.r.t. seams and so on.

For a fair comparison (though it probably won't make much difference),
you should run Enblend with

--fine-mask --no-optimize --compression=none

as multiblend's masks are always full resolution, it does no seam
optimisation, and it defaults to no compression instead of LZW (on my
machine multiblend spends more time reading and writing images than
actually doing the calculations).

> Two question though:
> - Is multiblend GPL (V2/V3)?
> - Does multiblend contain patent/license bound code?

I've added the GPL v2 to the top of multiblend.cpp, and I wrote every
line - not that that means much in these days of algorithm patents and
the like, but it should be safe.

David

[Harry van der Wolf]

Hi David,

2011/12/31 Monkey <davidh...@gmail.com>

> multiblend is indeed much, much faster then enblend. From the 3 comparing
> tests the resulting images were "equal" to me w.r.t. seams and so on.

For a fair comparison (though it probably won't make much difference),
you should run Enblend with

--fine-mask --no-optimize --compression=none

as multiblend's masks are always full resolution, it does no seam
optimisation, and it defaults to no compression instead of LZW (on my
machine multiblend spends more time reading and writing images than
actually doing the calculations).

I used --compression=LZW for both.

 

> Two question though:
> - Is multiblend GPL (V2/V3)?
> - Does multiblend contain patent/license bound code?

I've added the GPL v2 to the top of multiblend.cpp, and I wrote every
line - not that that means much in these days of algorithm patents and
the like, but it should be safe.

David

That's very nice.


You know it: users always ask for more :)
I have a simple compact camera and I'm always using jpegs, also for my output images. Is there a chance you could add jpeg support?


Harry

[Erik Krause]

Am 31.12.2011 19:54, schrieb Harry van der Wolf:

> You know it: users always ask for more:)

That's true! What I would very much like to see in multiblend is a seam
optimization like in smartblend. This would make multiblend a real
killer! Unfortunately the smartblend algorithm isn't known. There are
only some hints, f.e in
http://groups.google.com/group/hugin-ptx/msg/1ff668e2a06a38b1

Another idea would be a faster replacement for enfuse...

--
Erik Krause

[Jan Martin]

This might be obvious to coders, but I am stuck nevertheless.

Ubuntu 10.04.3 running on AMD Phenom II x6, 16GB RAM:

me@me-desktop:~/multiblend$ g++  -msse2 -O2 multiblend.cpp -ltiff -ltiffxx
me@me-desktop:~/multiblend$

It seems nothing happens?
What to expect?
How to fix?

Thanks,
Jan

--
You received this message because you are subscribed to the Google Groups "Hugin and other free panoramic software" group.
A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ
To post to this group, send email to hugi...@googlegroups.com

To unsubscribe from this group, send email to hugin-ptx+unsubscribe@googlegroups.com

[Harry van der Wolf]

2012/1/1 Jan Martin <janm...@diy-streetview.org>

This might be obvious to coders, but I am stuck nevertheless.

Ubuntu 10.04.3 running on AMD Phenom II x6, 16GB RAM:

me@me-desktop:~/multiblend$ g++  -msse2 -O2 multiblend.cpp -ltiff -ltiffxx
me@me-desktop:~/multiblend$

It seems nothing happens?
What to expect?
How to fix?

Thanks,
Jan

The compilaion is very fast. If you don specify an output a file a.out will be created.

Use: g++  -msse2 -O2 multiblend.cpp -ltiff -ltiffxx -o multiblend

and you will find a binary called multiblend (without extensions) in your folder.  You can (sudo) copy that one to /usr/local/bin or any other place of your liking.

Harry 

[kfj]

FWIW I'd like to add that the Windows EXE runs just fine under Wine
(at least here on my Kubuntu 11.4 32bit system). I used this command
line:

wine multiblend.exe --bgr -o xx.tif $(winepath -w <images>)

with <images> being the images to be blended. Note the use of winepath
to make the EXE think it's reading windows paths, and note also I
needed the --bgr switch here as well. This BGR thing happened to me
recently using opencv which also annoyingly swaps the R and B
channels. Any relations of multiblend to opencv?

And... it definitely feels fast :)

Kay

[Photogryph17]

I have compiled enblend on 64 bit linux, so wouldn't that mean that
enblend is capable of being 64 bit.

On Dec 28 2011, 3:45 pm, Monkey <davidhorma...@gmail.com> wrote:
> Hi all,
>
> I've developed an alternative to Enblend which I hope might find some
> interested users here. It's not a better blender, and it lacks many of
> Enblend's features, but it has two redeeming qualities - the first is
> a 64-bit version, which means it can use more memory, and the second
> is that it is much faster. In testing on a 560 megapixel 7x7 mosaic,
> it was 172x faster than Enblend (at least; Enblend ran out of memory
> before it could finish).
>
> It should work straight out of the box as Hugin's "alternative Enblend
> program". There is some more information about how it works and its
> (very few) options athttp://horman.net/multiblend/
>
> Download:http://horman.net/multiblend/multiblend0.1.zip(Windows
> only)
>
> I'd appreciate any feedback, especially bug reports.
>
> David

[Harry van der Wolf]

2012/1/1 Photogryph17 <gvand...@gmail.com>

I have compiled enblend on 64 bit linux, so wouldn't that mean that
enblend is capable of being 64 bit.

Yes off course: enblend is capable of 64 bit. My Hugin bundles for OSX also come with 64bit enblend and enfuse.

(Well, actually: On OSX it is possible to build universal which means that the enblend and enfuse binaries inside Hugin are combined ppc/i386/x86_64 binaries and they adapt to the native architecture they run on).

Harry

[Monkey]

Wow, okay, where to start? :)

JPEG support: I guess this shouldn't be too hard to add, though it's
not a priority just now.

Seam optimisation: it would be nice, but even an optimised seam may
not be the best - and I'm not sure where to begin with the programming
of it. The same goes for 360 degree wrapping at the moment...

64-bit Enblend: this was something of an assumption on my part,
because as far as I can see there is no "official" 64-bit Windows
build.

BGR problem: I don't know what causes this - I assume there must be a
TIFF tag somewhere which specifies the swap, but I haven't been able
to identify it.


Harry, thanks for building the MacOS bundle!

David

[Tduell]

Hullo All,

On Jan 2, 8:38 am, Harry van der Wolf <hvdw...@gmail.com> wrote:
> 2012/1/1 Photogryph17 <gvander...@gmail.com>

>
> > I have compiled enblend on 64 bit linux, so wouldn't that mean that
> > enblend is capable of being 64 bit.

It builds OK here on Fedora 16 x86_64, using the following;

g++ -L/usr/lib64 -I/usr/include -msse2 -O2 multiblend.cpp -ltiff -o
multiblend

and runs OK.

I found that the --bgr switch is not required.

Cheers,
Terry

[Bart van Andel]

On Sunday, January 1, 2012 11:11:17 PM UTC+1, Monkey wrote:

JPEG support: I guess this shouldn't be too hard to add, though it's
not a priority just now.

Just an idea: why not use Freeimage [0] to do the image loading/saving? This adds support for a whole bunch of image file types (including but not limited to TIFF, JPG, PNG and also HDR, EXR and multiple RAW formats) without having to write your own compatibility layer to account for differences in image data convention. It has dual license [1]: GPLv2 for OSS projects like Hugin, or a proprietary license for use in commercial projects.

I'm actually wondering why Hugin, Enblend and other tools aren't using this library. Besides its support for a wide range of image formats, apparently it includes routines to easily transform image data into OpenGL formats too. Not sure if it supports cropped TIFF though, I haven't really delved into the matter.

[0] http://freeimage.sourceforge.net/features.html

[1] http://freeimage.sourceforge.net/license.html

--

Bart

[Erik Krause]

Am 29.12.2011 17:48, schrieb Monkey:
> Non-compressed executables:
>
> http://horman.net/multiblend/multiblend0.1uncomp.zip

Many thanks for that! However, the program needs the Microsoft Visual
C++ 2010 Redistributable Package if you don't have Visual C++ installed.
It is available from http://tinyurl.com/2cq5sjm (x86) or
http://tinyurl.com/6u9xwte (x64).

The program works very fast indeed, but I got the reversed color
channels as well. http://horman.net/multiblend/multiblend0.1a.zip gives
me the virus warning, too. I ignored it, but the program didn't work
either, it stopped with a windows error (Windows 7 x64).

--
Erik Krause
http://www.erik-krause.de

[Gnome Nomad]

I've moved all of my panorama work to 64-bit Debian Sid, which has
64-bit packages of all the Hugin stuff, including enblend and enfuse.

--
Gnome Nomad
gnome...@gmail.com
wandering the landscape of god
http://www.cafepress.com/otherend/

[kfj]

On 2 Jan., 00:09, Bart van Andel <bavanan...@gmail.com> wrote:

> I'm actually wondering why Hugin, Enblend and other tools aren't using this
> library.

> [0]http://freeimage.sourceforge.net/features.html

This looks really nice! Wonder why I haven't stumbled upon it in my
endless quest to find the 'best' image processing library. Thanks for
the hint. The Python bindings look a bit rough and ready, though...

http://freeimagepy.sourceforge.net/

Kay

[Erik Krause]

Am 01.01.2012 23:15, schrieb Erik Krause:
> http://horman.net/multiblend/multiblend0.1a.zip gives
> me the virus warning, too. I ignored it, but the program didn't work
> either, it stopped with a windows error (Windows 7 x64).

Sorry, forgot to mention that the 0.1a x86 version works as expected.
It's the x64 version that crashes. I guess it's Mpress...

[Monkey]

http://horman.net/multiblend0.1a.zip is now the uncompressed
executables.

David

[Erik Krause]

Am 02.01.2012 11:55, schrieb Monkey:
> http://horman.net/multiblend0.1a.zip is now the uncompressed
> executables.

Many thanks! I guess it should be
http://horman.net/multiblend/multiblend0.1a.zip

[Erik Krause]

Am 01.01.2012 23:11, schrieb Monkey:
> Wow, okay, where to start?

My first priority would be 360� wrapping support. This is essential not
only for spherical panoramas. If I would have to do it, I'd extend the
right border with the left half of the image and the left border with
the right half and then blend. But I guess this isn't efficient (I'm no
experienced coder)...

[Markku Kolkka]

2.1.2012 1:09, Bart van Andel kirjoitti:
> Just an idea: why not use Freeimage [0] to do the image loading/saving?

Another library worth checking out is OpenImageIO:
https://sites.google.com/site/openimageio/home
It includes a caching module for handling large images.

--
Markku Kolkka
markku...@iki.fi

[kfj]

On 29 Dez. 2011, 00:45, Monkey <davidhorma...@gmail.com> wrote:
> Hi all,
>
> I've developed an alternative to Enblend which I hope might find some
> interested users here. It's not a better blender, and it lacks many of
> Enblend's features, but it has two redeeming qualities

> ...

> It should work straight out of the box as Hugin's "alternative Enblend
> program".

I've given multiblend a spin, and it doesn't work for me. What happens
is that some areas of the output contain large-scale artifacts which
aren't merely blending errors but plain wrong. I had the erroneous
behaviour occur in 360X180 panoramas, and I assume that the complex
patterns of layered transparency resulting from warped fisheye images
(my 360X180s are usually 6 around, 1 up two down with a Samyang 8mm)
may be the root of the problem.

I sent a reduced set of sample images to the author to make sure it
wasn't just something my end, and he wrote back saying he could
reproduce the behaviour. He had some ideas about what might cause the
problems, but no immediate solution.

Have a look at the output I got at

http://dl.dropbox.com/u/52145569/IMG_2862_IMG_2870_mb.jpg

You'll notice the area around the nadir is totally wrong, and there's
a nasty glitch in the middle of the lake. Cropping the output to a
strip creates more errors:

http://dl.dropbox.com/u/52145569/IMG_2862_IMG_2870_mb2_strip.jpg

The PTO for the full panorama is

http://dl.dropbox.com/u/52145569/IMG_2862_IMG_2870_mb.pto

(I removed the CPs) The individual images are 16bit TIFF. I
doublechecked with JPEGs as input, the problem persisted, but the
colours changed - I had used the --bgr switch to swap the R and B
channels which was necessary for my 16bit TIFFs, but with JPEG input I
had to remove it.

It's hard to see the errors with an image set from ptodummy, since
everything is just blended to a mush, but it may be helpful to have a
look at the fast preview to see how the images are arranged. The
output was made from cropped partial images; when feeding in uncropped
TIFF multiblend died with an unhandled page fault.

With this problem, plus the missing wraparound (which is bad but much
less grave), plus the necessity of manually changing the --bgr
depending on source material - I'd recommend to use multiblend with
caution. I think it shouldn't be put into hugin bundles until these
issues are solved, much as I'd welcome a fast alternative to enblend.

Kay

[Harry van der Wolf]

2012/1/3 kfj <_k...@yahoo.com>

With this problem, plus the missing wraparound (which is bad but much
less grave), plus the necessity of manually changing the --bgr
depending on source material - I'd recommend to use multiblend with
caution. I think it shouldn't be put into hugin bundles until these
issues are solved, much as I'd welcome a fast alternative to enblend.

Kay

 Hi Kay,

Does this issue persist when using reduced size images resulting in a smaller pano (as also enblend sometimes has some (other) glitches with big panos)?

W.r.t. putting multiblend into hugin bundles:
- For release bundles I fully agree with you: no multiblend yet.
- For development bundles I would strongly suggest (and will do so myself) to include multiblend with Hugin as that's what development bundles are for, but to do it with a warning like "highly experimental but please test ... etcetera". The more people test, the faster bugs are found and hopefully fixed.

Harry

[Monkey]

A little more info on the bug Kay found:

It happens when an area of the mosaic is covered by two or more
images, and the particular layout of images around that area means
that multiblend decides that an image which doesn't actually cover
that area is the correct choice. I think (looking at the PTO) the
problem with Kay's nadir is that there are two nadir images, so there
is no area which is exclusively one image or the other from which the
seam can grow.

Possible workarounds could be to remove overlapped images from
consideration if the problem is detected and recalculate the seams
(though there may still be ambiguous cases that will cause the
problem, or you'd be losing out on images that should be kept, such as
one of the two nadir images above), or arbitrarily choosing an image
to represent the area (which then re-introduces the Enblend issue I
was trying to address with multiblend, that there is not a unique
solution). Perhaps there could be some semi-intelligent grouping done,
so the nadirs are seamed first, then the middle images, then the two
groups are seamed together (though again, there may be cases with no
unique solution).

Or maybe multiblend is only suited to narrower-FOV mosaics :(

David

[kfj]

On 3 Jan., 10:16, Harry van der Wolf <hvdw...@gmail.com> wrote:

> Does this issue persist when using reduced size images resulting in a
> smaller pano (as also enblend sometimes has some (other) glitches with big
> panos)?

If you think that 9 images of 12 MP each are big, what would you
consider small enough to justify errors along the lines of what I've
shown?

Anyway, I shrunk the images to .6 MP each, and the errors look
different, but they are still there. And it's not just a Linux
problem; I did a test yesterday on a VW running W7 and it was the
same.

> W.r.t. putting multiblend into hugin bundles:
> - For release bundles I fully agree with you: no multiblend yet.
> - For development bundles I would strongly suggest (and will do so myself)
> to include multiblend with Hugin as that's what development bundles are
> for, but to do it with a warning like "highly experimental but please test
> ... etcetera". The more people test, the faster bugs are found and
> hopefully fixed.

I don't quite understand why multiblend has to make it into any
bundles so quickly. It's just not ready yet. If anyone wants to
experiment with it, they are free to do so on the command line. This
can easily be done on Windows, and I've demonstrated how to do it with
wine under Linux as well. I don't know about MacOS, but maybe wine has
been ported to MacOS - or there is a similar mechanism to execute
Windows CLI programs. I see little point in verifying that the bugs
persist when multiblend is compiled on various different platforms.
Actually I see little point in porting it at all at the current state,
if running the Windows EXE works just fine (I don't know about MacOS).
- I'd see much more point in spending time on getting it debugged
properly before porting it.

If anyone is interested in using Windows software on Linux systems
with hugin (so, multiblend.exe as an alternative stitcher Program), I
have glue code to do that which I'll happily share.

Kay

[Jim Watters]

David,

I am curious of the algorithm you use to determine the seams. The code is well
organized but not well documented.

Does Multiblend look at the masks of the input images, or just the rectangular
bounding box the image? Once it has been determined that a pixel should come
from a particular image is there preference given to the adjacent pixels to come
from the same image?

The example from Kay looks like it alternates from one image to the next, giving
horizontal lines in the lake and vertical lines in the nadir. The two nadir
images don't have the exact yrp, but even so, preference has to be given to one
image over the other.

Jim

--
Jim Watters
http://photocreations.ca

[Jan Martin]

Kay,

why on earth would one want to use the Windows version of multiblend with hugin on Linux?
David updated his website, the Linux source is available since this weekend:
http://horman.net/multiblend

Just do

g++  -msse2 -O2 multiblend.cpp -ltiff -ltiffxx -o multiblend

Then as root copy the new multiblend file to e.g. /usr/local/bin
Set up Hugin to use it. Thats all.

David found out that by reducing blending levels by one using  -l -1
the seam at the 0-360 boundary vanishes.
Anyone to test -l -1 with your images?

Keeping in mind that multiblend has been published just a week ago, I am happy to have a very fast alternative to enblend that works well for my specific usage case.

The rest will come with time,

Jan

[Monkey]

Jim Waters wrote:

> I am curious of the algorithm you use to determine the seams. The code is well
> organized but not well documented.

I think it's pretty generous to even call it organized, but thanks ;)

> Does Multiblend look at the masks of the input images, or just the rectangular
> bounding box the image? Once it has been determined that a pixel should come
> from a particular image is there preference given to the adjacent pixels to come
> from the same image?

It looks at the masks of each image, and first builds what I call the
XOR map - showing only those areas where one image's pixels are
present. From there the pixels spread outward and create a distance
map (not a true Euclidean distance transform, but good enough). This
is essentially what Enblend does (but it <i>does</i> use a true EDT),
but seaming more than two images requires a bit of extra care to be
taken.

(actually the XORing and the first stage of the distance transform are
combined, which makes for some tricky-to-read code)

> The two nadir images don't have the exact yrp, but even so, preference has to be given to one
> image over the other.

Ideally yes, but the choice may have to be arbitrary (as it would be
in Enblend, since it would be determined by input order).

On Jan 3, 3:53 pm, Jan Martin <janmar...@diy-streetview.org> wrote:
> David found out that by reducing blending levels by one using  -l -1
> the seam at the 0-360 boundary vanishes.
> Anyone to test -l -1 with your images?

I should point out this isn't a general cure - some users may have to
use lower (more negative) numbers, and this will affect how wide the
blending is across the pano. I've had some ideas on other ways to deal
with the boundary - one of them could give a "perfect" result but will
require a lot of changes and may be inefficient (I love efficiency!)

Is there someone who can change the title of this discussion, as
multiblend is no longer Windows only?

David

[kfj]

On 3 Jan., 16:53, Jan Martin <janmar...@diy-streetview.org> wrote:
> Kay,
>
> why on earth would one want to use the Windows version of multiblend with
> hugin on Linux?

I thought it might be easier for the author initially to only get it
to run properly on one platform. I think this helps to narrow down
problems more quickly, rather than having platform issues on top of
everything.

> David updated his website, the Linux source is available since this weekend:http://horman.net/multiblend

> Just do
> g++  -msse2 -O2 multiblend.cpp -ltiff -ltiffxx -o multiblend
>
> Then as root copy the new multiblend file to e.g. /usr/local/bin
> Set up Hugin to use it. Thats all.

Thanks for telling me ;-)
I'll see if a Linux build on this system produces the same errors.
... done. the problem is still there.

> David found out that by reducing blending levels by one using  -l -1
> the seam at the 0-360 boundary vanishes.
> Anyone to test -l -1 with your images?

I never saw the 360-0 boundary much with my test images - just a hint
of it in the sky (the images are photometrically optimized). But with
the -l -1 setting, I can't see it any more. The other problem is there
just the same with -l -1. And with the native Linux version, I need
the --bgr switch as well.

> Keeping in mind that multiblend has been published just a week ago, I am
> happy to have a very fast alternative to enblend that works well for my
> specific usage case.

Jan, would you like to share what your usage case is? Maybe this would
help narrowing down were the problems come from. I noticed that the
strong artifacts around the nadir disappeared when I had masks active
in the area (like, around my feet). And the artifacts higher up seem
to depend on the precise position of the images - they show up
sometimes here, sometimes there and sometimes not at all.

I'd also like a fast alternative to enblend. So, David, don't be
disheartened. I'm sure it's just a silly mistake somewhere and you'll
sort it out.

Kay

[Harry van der Wolf]

2012/1/3 Monkey <davidh...@gmail.com>

Is there someone who can change the title of this discussion, as
multiblend is no longer Windows only?

David

This is a mailing list, not a forum. Just start a new mail (and somewhere in your mail refer to this mail thread if necessary <http://groups.google.com/group/hugin-ptx/browse_thread/thread/b08211b2659a7eab>).
But simply starting a new one might be better. Yoy could also name it to the version starting a new mail thread upon a new (sub)version.

Harry

[Monkey]

On Jan 3, 5:31 pm, kfj <_...@yahoo.com> wrote:

> And with the native Linux version, I need
> the --bgr switch as well.

Do you mean that you *didn't* need the switch on Windows, with the
same images?

> I'd also like a fast alternative to enblend. So, David, don't be
> disheartened. I'm sure it's just a silly mistake somewhere and you'll
> sort it out.

There's no mistake, as such, just a failure to anticipate certain
cases ;)

By activating masks on your images (or by altering image positions),
you are probably removing the "total overlap" problem and giving both
nadir images their own footholds in seam creation.

David

[kfj]

On 3 Jan., 18:18, Monkey <davidhorma...@gmail.com> wrote:

> > The two nadir images don't have the exact yrp, but even so, preference has to be given to one
> > image over the other.
>
> Ideally yes, but the choice may have to be arbitrary (as it would be
> in Enblend, since it would be determined by input order).

processing in input order is not an arbitrary choice. If it is
consistently used, you can count on it and work accordingly. I rely on
it when I put my zenith and nadir images at the end of the list - the
6 around already settle most of the pano and the blender can just pick
the bits to fill out the missing areas around the zenith and the
nadir. Works just fine.

> > And with the native Linux version, I need
> > the --bgr switch as well.

> Do you mean that you *didn't* need the switch on Windows, with the
> same images?

I think it depended on input type - JPEG didn't need it, TIFF needed
it, if I recall correctly. Didn't I write all of this in great detail?
Sory, I may have been sloppy...

Kay

[Naked Robot]

I agree (with both Harry and Erik)

seam optimization is the really big obvious missing feature in multiblend that would make it a truly amazing tool.

one idea - i see multiblend can blend images that are not overlapping - so maybe the blending part of the tool is already done, and now we need another tool, for "cutting" the source images in the right places.

at any rate, wherever the 'cutting' happens, i hope that multiblend evolves into the great tool I think it's destined to be!



On Sunday, January 1, 2012 2:31:49 PM UTC+1, Erik Krause wrote:

Am 31.12.2011 19:54, schrieb Harry van der Wolf:

> You know it: users always ask for more:)

That's true! What I would very much like to see in multiblend is a seam
optimization like in smartblend. This would make multiblend a real
killer! Unfortunately the smartblend algorithm isn't known. There are
only some hints, f.e in
http://groups.google.com/group/hugin-ptx/msg/1ff668e2a06a38b1

Another idea would be a faster replacement for enfuse...

--
Erik Krause

[Erik Krause]

Am 05.01.2012 21:32, schrieb Naked Robot:
> we need another tool, for "cutting" the source images in the right places.

This is the challenge. Finding the best seam line is the hard part, that
what makes smartblend really smart! Michal Norel gave a hint:
Psychovisual Error and Kolmogorov Min Cut (whatever this means). AFAIK
Kolmogorov Min Cut was already discussed for enblend (could be the
current seam optimization does this already).

I've no idea whether this is feasible: What about using multiblend as an
alternative blending engine for enblend? I guess much of the work is
done already in enblend (read different image formats, 360�-wrapping,
seam optimization etc.), so why invent the wheel again?

Or: Since both projects are GPL, why not borrow code or algorithms from
each other?

[kfj]

On 6 Jan., 00:38, Erik Krause <erik.kra...@gmx.de> wrote:
> Am 05.01.2012 21:32, schrieb Naked Robot:
>
> > we need another tool, for "cutting" the source images in the right places.
>
> This is the challenge. Finding the best seam line is the hard part, that
> what makes smartblend really smart! Michal Norel gave a hint:
> Psychovisual Error and Kolmogorov Min Cut (whatever this means). AFAIK
> Kolmogorov Min Cut was already discussed for enblend (could be the
> current seam optimization does this already).

Intelligent seam placement is also computationally expensive. I
remember when enblend changed to the new algorithm recently that made
it more smartblendish, processing times went up noticeably. I'd be
curious to know how much of the processing time in enblend is devoted
to the actual blending, and how much needs to be invested in seam
placement.

Kay

Kay

[Monkey]

On Jan 5, 11:38 pm, Erik Krause <erik.kra...@gmx.de> wrote:
> What about using multiblend as an
> alternative blending engine for enblend? I guess much of the work is
> done already in enblend (read different image formats, 360 -wrapping,
> seam optimization etc.), so why invent the wheel again?

One reason (the main reason, before I discovered how much quicker I
could get the blending done) for writing multiblend in the first place
was to improve on the way Enblend creates its initial seams before
optimisation (though as has been discovered multiblend's approach can
cause problems, which need fixing). 360 degree wrapping is a function
of the blending process, so a multiblend-specific solution needs to be
found (I suspect Enblend's solution stems from the fact that it does
many separate blends, so won't be compatible with multiblend). So
while there may be ideas multiblend can borrow from Enblend and vice
versa, I don't think a hybrid would be an improvement.

Even optimised seams won't always give the best results. This was
another aim of multiblend, to one day incorporate a seam editor (the
ancient GUI version of multiblend had a proof-of-concept of this) so
you can do tricks like drawing snaking lines back and forth across
water to hide the seam, or around people and other moving objects
(though the latter can be achieved using Hugin masks).

David

[Erik Krause]

Am 06.01.2012 08:36, schrieb kfj:

> Intelligent seam placement is also computationally expensive.

Not necessarily, as photoshop autoblend shows. It is the fastest blender
with the best result regarding seam placement in Hans Nyberg's test:
http://www.panoramas.dk/panorama/CS3-autoblending.html

And Helmut Dersch implemented an experimental seam optimization in his
PTStitcherNG, which is very fast but might fail miserably due to the
streaming manner it works: "early wrong decisions of the seam optimizer
can not be corrected later and may result in disasters." (Taken from
http://webuser.hs-furtwangen.de/~dersch/PTStitcherNG/Changes.txt )

However, even if seam optimization takes longer it is inevitable for
some kinds of panoramas (f.e. crowds or windy leaves). Even slight
misalignments in structured ground (which otherwise result in the well
known "smearing") benefit from seam optimization.

[Harry van der Wolf]

2012/1/6 Monkey <davidh...@gmail.com>

 360 degree wrapping is a function
of the blending process, so a multiblend-specific solution needs to be
found (I suspect Enblend's solution stems from the fact that it does
many separate blends, so won't be compatible with multiblend). So
while there may be ideas multiblend can borrow from Enblend and vice
versa, I don't think a hybrid would be an improvement.

I do off course see the importance of the 360 degree wrapping. However, for me it is completely UNnecessary. I use a compact camera and have made only 2-5 360 degree panos over the past year, and never with nadir images.
I simply make wide angle panos or "high resolution" images the way Max Lyons does (1). For me the memory consumption is of far more importance than the 360 degree seam.
Apart from the memory consumption multiblend is already for me an excellent replacement for enblend.

Harry


(1): <http://www.tawbaware.com/maxlyons/index.html>

[Carlos Eduardo G. Carvalho (Cartola)]

I have already thought of editing seams graphically, I think I would appreciate such possibility and I think it would be a little better than masks, cause when you do masks there will still be a seam decision after that and you can't preview where it's going to be. Sometimes when I do masks I have to redo them after blending to adjust an unexpected result. Thanks to multiblend it is much faster now :)

Maybe it could have an option to accept or not seams created in hugin preview with Bézier curves or something like that. Maybe the actual fast algorithm could be used to create the initial visual seams on hugin preview and make it editable and pass it back to a final blending.

Thanks,

Carlos E G Carvalho (Cartola)
http://cartola.org/360

2012/1/6 Monkey <davidh...@gmail.com>

--
You received this message because you are subscribed to the Google Groups "Hugin and other free panoramic software" group.
A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ
To post to this group, send email to hugi...@googlegroups.com
To unsubscribe from this group, send email to hugin-ptx+...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx

[Ian Tindale]

Whereas for me, by far most of my hugin use is 360x180 using a Samyang 8mm fisheye, with a minority of it being "joiners" of partial panoramas shot with something like the 17mm pancake on the Olympus E-P1. 

What if it could, as a short-cut, optionally do two runs, one starting from where it starts and ends where it ends currently, and a second pass, starting from the middle pic and ending back near the middle again. Then somehow aggregate or blend the two passes to dodge the two seams.

[Rogier Wolff]

On Fri, Jan 06, 2012 at 09:52:29AM -0200, Carlos Eduardo G. Carvalho (Cartola) wrote:
> I have already thought of editing seams graphically, I think I would
> appreciate such possibility and I think it would be a little better than
> masks, cause when you do masks there will still be a seam decision after
> that and you can't preview where it's going to be. Sometimes when I do
> masks I have to redo them after blending to adjust an unexpected result.
> Thanks to multiblend it is much faster now :)

I personally think that the seam-selection process should be separate
from the blender.

So... A way to represent the seams has to be found, and multiblend
should be able to use a provided seam. As it works now, multiblend can
continue to do the seam-selection itself it none is provided.

Then.... a commandline interface for the seams may be defined. So
pro-users can define a seam themselves.

For mortals a gui-seam-editor may be provided.

A commandline option on multiblend should allow it to export the seams
it would make. So a gui-seam-editor can ask multiblend for the default
seams, present them to the user and then allow the user to change
them.

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.

[Naked Robot]

ugh!

I'm totally against the idea of manual seam editing. What are we, clerics copying documents with a pen? :-DDD We've nearly reached the point where control points don't need to be manually placed (although, I know of people who *like* placing control points manually)
So many other parts of panoramic imaging have been automated. What about seam placement?

I would prefer not to edit control points, or seams. I would prefer to shoot panoramas, go home, stitch my panos automatically, while I am playing with my kids. ;-)

[Frederic Da Vitoria]

2012/1/6, Naked Robot <360c...@gmail.com>:

I don't think the idea was to require manual editing, only to allow
it. Just as sometimes automatic CP does not work as well as manual
CPs, manual seam adjustment could sometimes allow us to improve less
than perfect automatically generated seams.

--
Frederic Da Vitoria
(davitof)

Membre de l'April - « promouvoir et défendre le logiciel libre » -
http://www.april.org

[Carlos Eduardo G. Carvalho (Cartola)]

That's it!!

> --
> You received this message because you are subscribed to the Google Groups "Hugin and other free panoramic software" group.
> A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ
> To post to this group, send email to hugi...@googlegroups.com
> To unsubscribe from this group, send email to hugin-ptx+...@googlegroups.com
> For more options, visit this group at http://groups.google.com/group/hugin-ptx
>

--

[Erik Krause]

Am 06.01.2012 12:52, schrieb Carlos Eduardo G. Carvalho (Cartola):
> I have already thought of editing seams graphically, I think I would
> appreciate such possibility

PTStitcherNG allows to edit seams graphically:
http://webuser.hs-furtwangen.de/~dersch/seam/s3.html