Enblend performance on mosaics?

[paul womack]

I recently did a final stitch on a 175 image (3264x2448, i.e. 8 Mpix)
to a 33054x17293 output.

It took around 2 hours on a 8Gb laptop, CPU i5-3210M CPU @ 2.50GHz.
I used a script to perform the blend from the command line.

Is there any way to perform the blend in stages (either row at a time,
column at a time, or quarters/eighths at a time), that will improve performance
in the special case of a gigapix/mosaic?

BugBear

[Terry Duell]

Hello Paul,

On Mon, 07 Dec 2015 20:25:02 +1100, paul womack <pwo...@papermule.co.uk>
wrote:

I can't see a way to do that with enblend, but others may know some tricks.
Another approach, is to split the stitch up into quarters/eighths, stitch
and blend each, then stitch and blend those results. Just a quick thought.
Also...does your laptop gpu support opencl?

Cheers,
--
Regards,
Terry Duell

[David W. Jones]

I've done that on a 32-bit 2GB RAM single core Intel Celeron. Stitch in
bits at a time. Took about 10 hours.

> Also...does your laptop gpu support opencl?

OpenGL, perhaps you mean? ;)

--
David W. Jones
gnome...@gmail.com
wandering the landscape of god
http://dancingtreefrog.com

[Terry Duell]

Hello David,

On Tue, 08 Dec 2015 16:39:48 +1100, David W. Jones <gnome...@gmail.com>
wrote:

>
>> Also...does your laptop gpu support opencl?
>
> OpenGL, perhaps you mean? ;)
>

No, opencl <https://www.khronos.org/opencl/>.
The current enblend source supports opencl, and may provide an improvement
in performance...not sure, I currently don't have the hardware to try it.

[bugbear]

Terry Duell wrote:
> Hello Paul,

>>

>> Is there any way to perform the blend in stages (either row at a time,
>> column at a time, or quarters/eighths at a time), that will improve performance in the special case of a gigapix/mosaic?
>>
>
> I can't see a way to do that with enblend, but others may know some tricks.
> Another approach, is to split the stitch up into quarters/eighths, stitch and blend each, then stitch and blend those results. Just a quick thought.
> Also...does your laptop gpu support opencl?

I've written a perl script to "chop up" the blend;
unfortunately, doing a quick low res test run, one of the quadrants reported:

enblend: info: loading next image: mapped/big0103.tif 1/1
enblend: info: loading next image: mapped/big0102.tif 1/1
enblend: warning: failed to detect any seam
enblend: mask is entirely black, but white image was not identified as redundant
enblend: info: remove invalid output image "1x0sub.tif"

So I didn't get my quadrant output.

And yet the "full set" of images blends OK.

BugBear

[bugbear]

I've been testing (on medium res images) that fit easily within my current RAM.

It appears on testing so far that blending the images into rows first,
then blending the rows, so that the vertical seams are small, gives a great saving on CPU.

I will do the "near the limit" memory test tonight, when I don't need my laptop
to be responsive to me...

BugBear

[Monkey]

You might save time by pre-merging alternate images in each row - not blending them, but just joining them into a single image. Then you end up with two images:

1-3-5-
-2-4-7

which can blended in one enblend step. This should be a lot quicker.

One of enblend's big problems, as far as I can tell, is that it adds each image to the blend one-by-one, adding it to an intermediate image which gets bigger all the time, so enblend gets slower and slower with each image. Removing all those intermediate steps by the method above should be a great saving.

There are quicker (albeit potentially lower quality) blenders ;) http://horman.net/multiblend/

You won't be able to blend an entire gigapixel panorama with multiblend and 2gb, though - it's a memory hog. Whatever you can fit in RAM will blend a lot quicker though.

[Monkey]

The problem with your "quadrant" plan may be down to the order you supply the images on the command line. It may be that each image must be connected to the previous images. So if you had 9 images:

ABC
DEF
GHI

And you supplied them in the order A,B,C,H... enblend might be able to blend A,B,C but when it comes to H there is no overlap (yet). If you supplied them instead in alphabetical order, the blend might be successful.

The full set may be okay because presumably you are supplying them in the order you shot them, in some kind of continuous/snaking grid pattern.

NB Enblend's output differs depending on the order images are supplied on the command line.

[Harry Saffren]

You can get greatly decreased blend times by using the older version of enblend 4.0. and using sRGB color space, (not CIECAM color space).  The current version of enbled, 4.1.3, seems to be optimized for CIECAM color space, but at the expense of working in sRGB color space. I routinely blend 45 to 60 images with very acceptable render times using enblend 4.0 that shipped with Hugin 2012.

Here are some times of test blends that I made from the command line using enblend 4.0 and enblend 4.1.3 with both CIECAM color space and sRGB color space (CIECAM set to off).  Note that enblend 4.0 defaults to sRGB (CIECAM=off) and enblend 4.1.3 defaults to CIECAM=on. And the two versions use different flag to turn CIECAM on or off.

Enblend Render Times for 31 images (3474x5211 pixels each, 8 bit Tifs) for a final image at 21322x16345 pixels

(Windows 7-64bit, 16 Gigs Ram, i7-2600k @ 4.2GHz)

Times are for Enblend run from the command line on the same set of images remapped by nona

Enblend 4.0      CIECAM=off (default)   render time:   5.5 minutes

Enblend 4.0      CIECAM=on                 render time: 97.5 minutes

Enblend 4.1.3   CIECAM=off                 render time: 21.0 minutes

Enblend 4.1.3   CIECAM=on (default)   render time: 62.0 minutes

(Hugin 2015 Builtin Blender + GPU for remapping in Nona the render time is 3 minutes including time for remapping)

As you can see Enblend 4.0 CIECAM=off is 5.5 minutes versus 62 minutes for Enblend 4.1.3 CIECAM=on

Also, on my system using the GPU for remapping in Nona yields a  big time reduction for remapping the images.

[David W. Jones]

On 12/07/2015 10:37 PM, Terry Duell wrote:
> Hello David,
>

> On Tue, 08 Dec 2015 16:39:48 +1100, David W. Jones wrote:
>
>>> Also...does your laptop gpu support opencl?
>>
>> OpenGL, perhaps you mean? ;)
>
> No, opencl <https://www.khronos.org/opencl/>.
> The current enblend source supports opencl, and may provide an
> improvement in performance...not sure, I currently don't have the
> hardware to try it.
>
> Cheers,

Ah, thanks. I see Debian has OpenCL available. Does Hugin support its
use if I install it? My laptop has an Haswell i7 processor.

[Terry Duell]

Hello David,

On Wed, 09 Dec 2015 18:25:07 +1100, David W. Jones <gnome...@gmail.com>
wrote:

> On 12/07/2015 10:37 PM, Terry Duell wrote:
>> Hello David,
>>
>> On Tue, 08 Dec 2015 16:39:48 +1100, David W. Jones wrote:
>>
>>>> Also...does your laptop gpu support opencl?
>>>
>>> OpenGL, perhaps you mean? ;)
>>
>> No, opencl <https://www.khronos.org/opencl/>.
>> The current enblend source supports opencl, and may provide an
>> improvement in performance...not sure, I currently don't have the
>> hardware to try it.
>>
>> Cheers,
>
> Ah, thanks. I see Debian has OpenCL available. Does Hugin support its
> use if I install it? My laptop has an Haswell i7 processor.
>

I can't find any reference to the use of opencl in the hugin source.
The current enblend source (4.2) does support opencl, but I have no idea
to what extent.
Hopefully others can elaborate on that.

[bugbear]

bugbear wrote:

>
> It appears on testing so far that blending the images into rows first,
> then blending the rows, so that the vertical seams are small, gives a great saving on CPU.
>
> I will do the "near the limit" memory test tonight, when I don't need my laptop
> to be responsive to me...
>
> BugBear
>

Short version: blend in a row-based manner for best performance.

Long Version:

OK; I've upped the test size; the output is now 33054x17290, (~0.5 GigaPixel)

The mapped TIFFs are 3.2 G, the pano roughly 15 columns x 11 rows of 8 MegaPixel images..

Mapping took from 17:24:16 until 17:44:39, around 20 minutes.

Blending:

1st run was done by creating 8 "row" panos; blending the rows took:
159,146,*728,154,164,*522,140,*512 seconds for a total 2525 seconds, or 42 minutes.

Since the "true" pano has 11 rows, the longer times are where 2 rows where merged.
Note that the time goes up by more than a factor of 2, more like 3.5. Worse than linear degradation.

Merging the rows into a final pano was done in 2 ways; first, by combing a tree of pairs,
and then "in one go";

Tree of pairs took 2408 second, "in one go" took 3552 seconds.

So; best blend time would be use the "pairs" tree, for a total of 2525 + 2408 = 4933 - 82 minutes.

I finally did a control run, simply letting enblend loose;
It had loaded 140 of 173 image after 45610 seconds (12 hours), when I killed it.

My enblend args are:
/usr/bin/enblend -m 4500 --compression=packbits

Any details about my system and software that are needed to interpret these results - just ask.

My "take home" is that performing sub-blends in a row orientated fashion is a MASSIVE win.

I do not know if this is due to better memory usage (rowed/striped access to memory is hugely better than columnar),
or wether is influences the seam calculations.

BugBear

[bugbear]

Harry Saffren wrote:
> You can get greatly decreased blend times by using the older version of enblend 4.0. and using sRGB color space, (not CIECAM color space). The current version of enbled, 4.1.3, seems to be optimized for CIECAM color space, but at the expense of working in sRGB color space. I routinely blend 45 to 60 images with very acceptable render times using enblend 4.0 that shipped with Hugin 2012.
>
> Here are some times of test blends that I made from the command line using enblend 4.0 and enblend 4.1.3 with both CIECAM color space and sRGB color space (CIECAM set to off). Note that enblend 4.0 defaults to sRGB (CIECAM=off) and enblend 4.1.3 defaults to CIECAM=on. And the two versions use different flag to turn CIECAM on or off.
>
> Enblend Render Times for 31 images (3474x5211 pixels each, 8 bit Tifs) for a final image at 21322x16345 pixels
> (Windows 7-64bit, 16 Gigs Ram, i7-2600k @ 4.2GHz)
> Times are for Enblend run from the command line on the same set of images remapped by nona
>
> Enblend 4.0 CIECAM=off (default) render time: 5.5 minutes
> Enblend 4.0 CIECAM=on render time: 97.5 minutes
> Enblend 4.1.3 CIECAM=off render time: 21.0 minutes
> Enblend 4.1.3 CIECAM=on (default) render time: 62.0 minutes
> (Hugin 2015 Builtin Blender + GPU for remapping in Nona the render time is 3 minutes including time for remapping)
>
> As you can see Enblend 4.0 CIECAM=off is 5.5 minutes versus 62 minutes for Enblend 4.1.3 CIECAM=on
> Also, on my system using the GPU for remapping in Nona yields a big time reduction for remapping the images.

I'm running (on Ubuntu 14.04) Enblend 4.1.3

Compiled on lgw01-14 by Build Daemon user on Sun, Mar 19 2015, 14:37:40 GMT+0.

It is compiled with Extra feature: GPU acceleration: yes, Extra feature: OpenMP: no.

Sadly, on a test, the GPU support doesn't work; many warning messages, and it eventually hangs.

Moving to your point about ciecam I performed a low-res (final output 9444x4940) test, using my "row" strategy.

My ciecam args versus times in seconds were:
ARG --ciecam; TIME 4758
ARG --no-ciecam; TIME 241
ARG; TIME 245

It looks like my ciecam default is "off"; just as well, ciecam seems to slow
things down by a factor of about 19!!

BugBear

[bugbear]

Short version - row based blending RULES!

Long version:

I've re-done the stitch in my "best practice" manner, for a stitch
with a pano size at 35000 (actual image 33054x17290)

mapping
17:26:11 to 17:46:34, around 20 minutes, similar previous test, as expected

Pano is 15x11, so I stitched to exactly 11 sub rows, not 8 as before;

Stitching to 11 "subrows"
each sub-row took roughly 150 seconds, 1721 in total (29 minutes).

Stitching the sub-row, nested-pairwise:
2883 seconds (48 minutes). This is a bit longer than the pair-wise stitch
of 8 sub-runs of the first test, 2408, but the sub-row-creating benefits outweigh this.

Total enblend time is 1271+2883 = 4154 = 69 minutes.
(The best result from the previous test was 2525 + 2408 = 4933 - 82 minutes)

BugBear

[Terry Duell]

Hello Paul,

On Tue, 08 Dec 2015 08:45:18 +1100, Terry Duell <tdu...@iinet.net.au>
wrote:

I note that you have had some success stitching rows.
Further to my question, above re OpenCl, I was on the wrong track with
that. Whilst the current source does support OpenCL it is for use with
exposure weighting functions.
One thing that has since crossed my mind, but I don't think was discussed
in relation to your problem, is the use of OpenMP. Is your version of
Enblend built with OpenMP enabled?

[bugbear]

Terry Duell wrote:
>
> I note that you have had some success stitching rows.
> Further to my question, above re OpenCl, I was on the wrong track with that. Whilst the current source does support OpenCL it is for use with exposure weighting functions.
> One thing that has since crossed my mind, but I don't think was discussed in relation to your problem, is the use of OpenMP. Is your version of Enblend built with OpenMP enabled?

My build is GPU yes, OpenMP no.

Sadly, GPU doesn't work, since left with single thread, main CPU!!

I will check today wether the row trick effects low-res blending.

BugBear

[bugbear]

bugbear wrote:
>
> I will check today wether the row trick effects low-res blending.

Having set the pano to be total width 10000, I allowed enblend 4.5 Gb of RAM,
the output tiff is only 9444x4940, 180 Mb.

blending to create 11 subrows: 188 Seconds;

blending 11 subrows together: tree style: 75 seconds, single call to enblend; 73 seconds.

Single pass (175 small images, single call to enblend) 661 seconds.

So - the "row trick" seems to affect enblend seam behaviour (for want of a better word)
as well as memory handling.

Summary - use a row based sequence when stitching mosaic/gigapixel
images with enblend.

BugBear

[Luís Henrique Camargo Quiroz]

  Hi BugBear,

   Thanks for sharing all that with us!

   Luís Henrique

 BugBear

--
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/56701CD2.5020808%40papermule.co.uk.

For more options, visit https://groups.google.com/d/optout.

--

--
Luis Henrique Camargo Quiroz
http://luishcq.br.tripod.com - http://www.christusrex.org/www2/cantgreg
http://panoramaslh.alojamentogratuito.com/

[bugbear]

Luís Henrique Camargo Quiroz wrote:
>
> Hi BugBear,
>
> Thanks for sharing all that with us!

I was hoping someone with a little (or more) knowledge
of the internals of enblend to explain some of this.

I've been effectively black box/reverse engineering,
based on my own intuition.

It certainly appears that using enblend "naively"
for a mosaic is catastrophic.

But (to say the least) one way and another,
I "owe" the hugin/panotools community, so
this thread is perhaps a little karmic payback.

I will now attempt to refine and polish my test script for general
purpose use (it's currently got my pano name, and image/row
numbers hard coded...)

BugBear