Enblend/Enfuse 4.0 dev snapshots

[Ryan Sleevi]

I'm not sure if many people are aware, but there has been a lot of ongoing
development lately over in the repository for enblend/enfuse. Perhaps most
importantly, Christoph Spiel's staging branch has been fully merged in,
which introduces support for OpenMP on platforms that support it, as well as
resolving several long standing leaks and bugs.

I've gone and packaged up some snapshots for Windows users of the various
configuration options that are possible - OpenMP support, GPU support,
64-bit support, and posted them at
http://ryan.sleevi.com/files/enblend-enfuse-4.0/

In a change-up of things, I've gone ahead and linked them against the
DLL-based versions of the MS C/C++ Runtime (for various reasons), and I want
to make sure that process is working smooth for people. Most importantly, if
you're planning to mess with OpenMP, you'll need to make sure you have the
redistributable. Many already have the necessary files, as they have been
shipping for some time, but for those who have issue, the two links are:

x86 -
http://www.microsoft.com/downloads/details.aspx?familyid=9B2DA534-3E03-4391-
8A4D-074B9F2BC1BF Microsoft Visual C++ 2008 Redistributable Package (x86)
x64 -
http://www.microsoft.com/downloads/details.aspx?familyid=BD2A6171-E2D6-4230-
B809-9A8D7548C1B6 Microsoft Visual C++ 2008 Redistributable Package (x64)

This isn't an "official" release of 4.0 by any means, but this is an attempt
to get dev binaries out there, as well as a chance to try out a more
automated build system that should make it easier to package enblend/enfuse
and Hugin in the future, so feedback would be appreciated.

Cheers!

[Zoran Zorkic]

Tested it on some 10 remapped photos:
used enblend -v -o output.tif input*.tif
unless stated otherwise

GPU, SSE2: 108 sec
GPU, SSE2, -m 1900: 85 sec
OPENMP: 63 sec
OPENMP, SSE2: 63 sec
RELEASE: 112 sec
RELEASE, -m 1900: 89 sec

Test machine: Xp sp2 x86, e6...@3.35GHz 4gb ram, nVidia 9800GT 512mb

[Zoran Zorkic]

Continued:

ENBLEND 3.2, -m 1900: 72 sec

Test machine: Xp sp2 x86, e6550 3.35GHz 4gb ram, nVidia 9800GT 512mb,
fairly new drivers
(I just saw that google censored my cpu in the last post :D )

Old, 3.2, was crashing for me a lot lately on bigger projects, I'll
try to test it against this one when I find some time.

Also when running GPU --gpu i get the following warnings:
-------------------
: info: using graphics card: NVIDIA Corporation
: info: renderer: GeForce 9800 GT/PCI/SSE2
: info: GL info log
0(1) : warning C7531: global type sampler2DRect requires "#extension
GL_ARB_texture_rectangle : enable" before use
-------------------
...
enblend: info: state (130, 580) weight = nan
enblend: info: state (117, 580) weight = nan
enblend: info: state (104, 580) weight = nan
enblend: info: new estimate = (-2147483648, -2147483648)
enblend: warning: new mean field estimate outside cost image
-------------------

[Yuval Levy]

the next level would be to run this kind of tests in the installer and
select the appropriate version to be installed on the system.

If a dual core is already so much faster than GPU stitching, I'd tend to
install the OpenMP version on any x86 multi-core. Not sure about the old
multi-threading pentium. Leave the GPU accelerated only for people with
old boxes and poweful GPUs.

Yuv

[Zoran Zorkic]

Got this after trying to blend a 360x180 from Hugin 2009.1.0.4263:

enblend: unrecognized wrap-around mode "-f3000x1500"

Probably because enblend was called with "-w -f3000x1500".

[J. Schneider]

Fine! I tried the x86 OpenMP, SSE2 version (assuming that this is right
for a core2duo).
I copied just enblend.exe into my hugin/bin directory (latest available
build).
The error I get looks not like it's a problem of MP or the like, its
about an "unrecognized wrap-around mode". It won't let me copy the
output as the window disappears just after klicking OK (and before you
can't select text) but I felt this would happen and made a screenshot:
http://www.joachimschneider.info/enblend-error/enblend-error.gif
The first of the numbers mentioned is the width.

Any idea?

Btw, there are droplets supplied only for enfuse but not enblend. Is it
because those for enblend didn't need any changes and I can continue to
use them?

regards
Joachim

[Yuval Levy]

yes, there are some changes in how enblend / enfuse is called in 4.0

we will need to adapt this in Hugin - ideally with an enblend --version
to find out if we're using a "legacy" enblend-enfuse; and with the
Makefile adapted to the enblend-enfuse "generation" found on the machine.

Yuv

[J. Schneider]

Sorry, I was too fast posting; I recognized the cause was changed
options syntax for enblend. I have to review my enblend options in
hugin. But this probably means we need new droplets for enblend, too.
regards
Joachim

J. Schneider schrieb:

[Zoran Zorkic]

I think it could have been done more backward compatible way in
enblend.

Anyway, using OpenMP, SSE2 version (on a 20000x10000 pano) from
command line I quickly bails with just a:

enblend: out of memory
enblend: bad allocation

I guess this is cause it was compiled without image cache :/
Yay for 32-bit OSes!

And by the testing I've done, the next fastest is v3.2 :(

Is there a reason it wasn't compiled with image cache and OpenMP?

[Yuval Levy]

J. Schneider wrote:
> Sorry, I was too fast posting; I recognized the cause was changed
> options syntax for enblend. I have to review my enblend options in
> hugin. But this probably means we need new droplets for enblend, too.

https://sourceforge.net/tracker/?func=detail&aid=2853823&group_id=77506&atid=550441

[Ryan Sleevi]

> -----Original Message-----
> From: hugi...@googlegroups.com [mailto:hugi...@googlegroups.com] On
> Behalf Of Zoran Zorkic
> Sent: Monday, September 07, 2009 4:25 PM
> To: hugin and other free panoramic software
> Subject: [hugin-ptx] Re: Enblend/Enfuse 4.0 and Hugin
<SNIP>
>
> Is there a reason it wasn't compiled with image cache and OpenMP?
>

If I recall correctly, the cached file representation used by enblend has
not been made re-entrant/multi-threaded aware yet, so it causes some issues.

I'm not sure if any work has been done towards supporting it, but I suspect
it's not exactly an 'easy' task either, tracking 'hot' and 'cold' image
segments across multiple threads efficiently.

[Zoran Zorkic]

On Sep 7, 10:37 pm, "Ryan Sleevi" <ryan+hu...@sleevi.com> wrote:
>
> > Is there a reason it wasn't compiled with image cache and OpenMP?
>
> If I recall correctly, the cached file representation used by enblend has
> not been made re-entrant/multi-threaded aware yet, so it causes some issues.
>
> I'm not sure if any work has been done towards supporting it, but I suspect
> it's not exactly an 'easy' task either, tracking 'hot' and 'cold' image
> segments across multiple threads efficiently.

So not anytime soon? :(
Any workarounds? BTW shouldn't the OS do the swapping for Enblend? Or
they do, but I have a 32-bit one?

[Benjamin Schnieders]

Hi all,

just trying a selfcompiled v4.0 - stitching a pretty big project now.

Inspecting the enblend run with top I see that indeed enblend sometimes
uses more than 100% cpu - but never more than like 200%, usually it is
around 100% and from time to time there is a peak using somewhat more.
As I have a quadcore and I see it is perfectly used up by nona I'm a
little disappointed about enblend - was this a malconfiguration?

enblend verbose version info tells me:
enblend 4.0-b93c2aed500d

Extra feature: dmalloc support: no
Extra feature: image cache: no
Extra feature: GPU acceleration: yes
Extra feature: OpenMP: yes - version 2005-5
- support for nested parallelism
- support for dynamic adjustment of the
number of threads
- using 4 processors and up to 3 threads

Is this the up-to date version or id I compile something wrong?

Thanks :)
Benjamin

[Zoran Zorkic]

On Sep 7, 10:37 pm, "Ryan Sleevi" <ryan+hu...@sleevi.com> wrote:

> > Is there a reason it wasn't compiled with image cache and OpenMP?
>
> If I recall correctly, the cached file representation used by enblend has
> not been made re-entrant/multi-threaded aware yet, so it causes some issues.
>
> I'm not sure if any work has been done towards supporting it, but I suspect
> it's not exactly an 'easy' task either, tracking 'hot' and 'cold' image
> segments across multiple threads efficiently.

Tried using GPU, SSE2 and the regular release, they all die with :

enblend: out of memory
enblend: bad allocation

at some point. Is that expected or normal on win32?
They did accept -m parameter with no complaint.

OpenMP and GPU die after blending 5 photos, regular after 22 (of 44).
Is there a way to check why?

Well, back to 3.2 for the time being.

[cspiel]

On Sep 8, 1:33 am, Zoran Zorkic <zo...@gmx.net> wrote:
> Tried using GPU, SSE2 and the regular release, they all die with :
> enblend: out of memory
> enblend: bad allocation
> at some point. Is that expected or normal on win32?

Could you please give us the output of
enblend --version --verbose
as I suspect your version runs w/o image-cache &&
your images are large && your memory is scarce
(wrt the images' sizes).

> They did accept -m parameter with no complaint.

If you actually use a variant w/o image cache, you get
a warning for every option that is related to the image cache,
like
enblend: warning: option "-m" has no effect in this version of
enblend,
enblend: warning: because it was compiled without image cache
However, processing continues; it is just a warning.


/cls

[cspiel]

On Sep 8, 12:49 am, Benjamin Schnieders

<benjamin.schnied...@gmail.com> wrote:
> Inspecting the enblend run with top I see that indeed enblend sometimes
> uses more than 100% cpu - but never more than like 200%, usually it is
> around 100% and from time to time there is a peak using somewhat more.

First of all CPU load is a silly
measure. You don't look at your car's
(clunker's?) gas consumption and say: "5 MPG,
that must have been an awfully fast ride!" For
a user only wall-clock time matters.

Second, read about Amdahl's law
http://en.wikipedia.org/wiki/Amdahl's_law
It matters.

> As I have a quadcore and I see it is perfectly used up by nona I'm a
> little disappointed about enblend - was this a malconfiguration?

The current implementation does _not_ scale
well beyond two processors. The reasons for
this are yet unknown. You are welcome to run
Enblend with your favorite profiler, identify
the bottleneck(s), and send me a bunch of
patches that rectify the congestion.

> enblend verbose version info tells me:
> enblend 4.0-b93c2aed500d
>
> Extra feature: dmalloc support: no
> Extra feature: image cache: no
> Extra feature: GPU acceleration: yes
> Extra feature: OpenMP: yes - version 2005-5
> - support for nested parallelism
> - support for dynamic adjustment of the number of threads
> - using 4 processors and up to 3 threads
>

> Is this the up-to date version or did I compile something wrong?

Your revision is reasonably recent.
Thanks for including the full version
information!

IMO, you did nothing wrong. My results are
similar. Let's see what I've got. The Enblend
that came with my Debian distribution is

$ enblend --version
enblend 3.2-cvs
Extra feature: image cache
Extra feature: GPU acceleration

Using it to build a medium-sized pano (62MPixel,
see details if tiffinfo(1) output below) gives

$ /usr/bin/time enblend -o a.tif image-000[0-9].tif
...
700.13user 1.22system 11:41.69elapsed 99%CPU (0avgtext+0avgdata
0maxresident)k
2696inputs+509496outputs (14major+293908minor)pagefaults 0swaps


$ tiffinfo a.tif
TIFF Directory at offset 0xf8c4ab8 (260852408)
Subfile Type: (0 = 0x0)
Image Width: 14940 Image Length: 4365
Resolution: 150, 150 pixels/inch
Position: 0, 8.3
Bits/Sample: 8
Sample Format: unsigned integer
Compression Scheme: None
Photometric Interpretation: RGB color
Extra Samples: 1<unassoc-alpha>
Orientation: row 0 top, col 0 lhs
Samples/Pixel: 4
Rows/Strip: 17
Planar Configuration: single image plane


My 4.0pre version identifies itself as

$ ~/projects/enblend/BUILD/src/enblend -v -V
enblend 4.0-227a6153f072

Extra feature: dmalloc support: no
Extra feature: image cache: no
Extra feature: GPU acceleration: yes
Extra feature: OpenMP: yes - version 2005-5
- support for nested parallelism
- support for dynamic adjustment of the
number of threads

- using 4 processors and up to 4 threads

and (for the same panorama as above) shows the
following performance for different numbers of
threads

$ for n in 1 2 3 4; do \
echo "#th = $n"; \
OMP_NUM_THREADS=$n /usr/bin/time ~/projects/enblend/BUILD/src/
enblend image-000[0-9].tif; \
done
#th = 1
27.53user 2.76system 0:30.32elapsed 99%CPU (0avgtext+0avgdata
0maxresident)k
0inputs+509496outputs (0major+1316119minor)pagefaults 0swaps
#th = 2
31.02user 3.14system 0:27.37elapsed 124%CPU (0avgtext+0avgdata
0maxresident)k
0inputs+509496outputs (0major+1317014minor)pagefaults 0swaps
#th = 3
32.79user 3.23system 0:25.81elapsed 139%CPU (0avgtext+0avgdata
0maxresident)k
0inputs+509496outputs (0major+1308513minor)pagefaults 0swaps
#th = 4
37.42user 3.74system 0:25.73elapsed 159%CPU (0avgtext+0avgdata
0maxresident)k
0inputs+509496outputs (0major+1338474minor)pagefaults 0swaps

Oh! It is faster than 3.2, isn't it?

For 2 threads, we gain some 10% in performance
for 24% more CPU load; for 3 threads we gain
15% for 40% more CPU load. 4 threads obviously
suffer from stalls, contention, etc.


HTH,
Chris

[Benjamin Schnieders]

Hi Chris,

> First of all CPU load is a silly

> measure.[...] For

> a user only wall-clock time matters.
>

sure. I did not yet take times, but the new version is definitely faster
than the old one. Of course 3 busy-waiting cpus and only one doing
something useful will stress a 4-core cpu the same as 4 useful threads -
the same in 'top', different wall clock time.

> Second, read about Amdahl's law
> http://en.wikipedia.org/wiki/Amdahl's_law
> It matters.
>

I know Amdahl's law, (good old parallel programming lectures) but I
thought enblends work was somewhat simpler to split up than it seems.

> The current implementation does _not_ scale
> well beyond two processors. The reasons for
> this are yet unknown. You are welcome to run
> Enblend with your favorite profiler, identify
> the bottleneck(s), and send me a bunch of
> patches that rectify the congestion.
>

Can you propose a (free) multi-thread profiler for linux? (Looking out
for one for some time now...) If so, I'll have a look at it, enough of
exploiting hugin/panotools now, time to give something back ;)

> IMO, you did nothing wrong. My results are
> similar.

Fine :) I will check later how much faster enblend has become. I'm
missing the output which image is processed (or, is finished being
processed) a little...

Thanks for reply :)
Benjamin

[cspiel]

Hello Benjamin -

On Sep 9, 12:36 am, Benjamin Schnieders

<benjamin.schnied...@gmail.com> wrote:
> Can you propose a (free) multi-thread profiler for linux? (Looking out
> for one for some time now...) If so, I'll have a look at it, enough of
> exploiting hugin/panotools now, time to give something back ;)

I use TAU

http://www.cs.uoregon.edu/research/tau/home.php

because, sadly, I found out that my g++-4.3.2
does not produce reliable results when profiling
OpenMP code. As I consider optimizing without
profiling an entirely meaningless business, I
had to look for a profiler, too.

You might find that TAU-2.18.2p2 is not very C++
friendly, though. I have submitted some patches
to the TAU developers, which are already in
their CVS, but are not available to the general
public. Give me a buzz on private e-mail, if
you need more info.

BTW, TAU is tremendously more fun when operated
on top of a PerfCtr-enhanced kernel. :-(=)


Thanks,
Chris

[HansNyberg]

On Sep 7, 10:25 pm, Zoran Zorkic <zo...@gmx.net> wrote:
> On Sep 7, 10:11 pm, Yuval Levy <goo...@levy.ch> wrote:
>
> > Zoran Zorkic wrote:
> > > Got this after trying to blend a 360x180 from Hugin 2009.1.0.4263:
>
> > >enblend: unrecognized wrap-around mode "-f3000x1500"
>

> > > Probably becauseenblendwas called with "-w -f3000x1500".
>
> > yes, there are some changes in howenblend/ enfuse is called in 4.0

>
> > we will need to adapt this in Hugin - ideally with anenblend--version
> > to find out if we're using a "legacy"enblend-enfuse; and with the

> > Makefile adapted to theenblend-enfuse "generation" found on the machine.

>
> I think it could have been done more backward compatible way inenblend.

Yes of course it should be done backward compatible, actually I can
not see why there is a new command. Why not make Enblend working
properly with the current command for both ways. I can not see any
reason for having 2 commands.
As far as I know the -w command is the only command built in in any
stitcher, PTGui PTMac or Hugin.
It has to be backward compatible or you loose 90% of the users.

Hans

[Erik Krause]

Zoran Zorkic wrote:

> Probably because enblend was called with "-w -f3000x1500".

Probably. The problem is that enblend doesn't correctly parse the
command line. It expects a MODE setting after -w or --wrap (which are
synonymous). This is somehow contrary to the documentation which says:
"Specifying --wrap without MODE selects horizontal wrapping".

I suspect this will be corrected in the final version.

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